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OVERVIEW OF REPORT 


Network Systems Cor p or at i on s HYPERchannel network 
is a baseband, 50 Megabit per second, high speed local 
area network. HYPERchannel utilizes a Carrier Sense 
Multiple Access (CSMA) data trunk access protocol, with 
prioritized staggered delays. This network has the 
capability of interconnecting various computer 
resources o-f differing manufacture, into a single 
efficient computing facility. 

This network is currently in use at the Huntsville 
Operations Support Center (HOSC;. HOSC as a distributed 
computing system, is responsible for data acquisition 
and analysis during National Aeronautics and Space 
Adm i n i str at i on ' s (NASA;* Space Shuttle operations. HOSC 
also provides computing services for Marshall Space 
Flight Center's ( MFSC) non-mission activities. As 
mission and non-mission activities change, so do the 
support functions of HOSC change, demonstrating the 
need for some method of simulating activity at HOSC in 
various configurations 

The simulation developed in this work primarily 
models NSC's HYPERchannel network, since this network 
basically determines HOSC's efficiency in accomplishing 
its mission. The model simulates the activity of a 
steady-state network, reporting statistics such as, 
transmitted bits, collision statistics, frame sequences 
transmitted, and average message delay. These 
statistics may be used to evaluate such performance 
indicators as throughput, utilization, and delay. Thus 
the overall performance of the network may be 
evaluated, as well as predict inc possible overload 
condi t i ons . 

HOW TO REhD THIS REPORT 

This report is a fully detailed report concerning the 
inner workings of the HYPERchannel Local Area Network, 
Chapter 2; a description of the HOSC system. Chapter 3; 
a full detailed description of the simulation software 
(design architecture Chapter 4, individual software 
module description Appendix III); and a presentation of 
the simulation results for single and dual trunk 
operation, Chapter 5. The reader interested in a quick 
o verview and a survey of the HOSC system performance 
mav read Chapter 1 and Chapter 5 only . However 
knowledge of the HYPERchannel adapter's inner workings 
including message frame construction and timing is 
desirable. Chapter 2. 
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Chapter 1 
in troduc t i on 

1.1 NSC's HYPERchannel Local Area Network 

Network Systems Corporation's (NSC) HYPERchannel 
local area network is a widely used very high speed, 50 
Megabits per second, digital communications -facility. 
HYPERchannel utilizes microcomputer-based adapters and 
standard 75 ohm CATO coaxial cable as data trunks, to 
interconnect various computer resources within a 
computing installation. There are three types o-f 
adapters (Processor, Device, and Link) used to 

interface individual equipment to the network o-f data 
trunks. These adapters provide for: 

o interconnection of equipment from various 
manuf ac turers . 

o high performance communication between 
processors . 

o a sharing of peripheral systems between 
multiple processors. 

o realistic physical location of 
interconnected equipment. 

o increased utilization of interconnected 
equ i pmen t . 

o increased tolerance to individual 
equipment failures. 

Finally, Data movement within a HYPERchannel network is 
accomplished by use of frames and frame sequences. 
These frames contain the necessary information for 
addressing and routing, along with associated user 
messages and data. A sophisticated internal protocol 


is used to provide -for contention allocation, error 
detection, retransmission allocation, and data 
movement. These capabilities provide a reliable 
network that is irsensitive to con-figuration, and 
single points of failure. This interral protocol is 
the basis for HYPERchannel sys f em performance and will 
be described further in a subsequent chapter. 

1.2 HOSC System Overview 

The Huntsville Operations Support Center (HOSC), 
as implemented at the Marshall Space Flight Center 
(MSC) in Huntsville, Alabama, is a distributed computer 
resource facility. HOSC is designed to provide real 
time acquisition, analysis, and display of data during 
National Aeronautics and Space Administration's (NASA) 
space missions. HOSC provides support primarily for the 
Space Shuttle, Space Telescope, and Space Laboratory 
missions. Among the resources available at HOSC are 
various large minicomputers and peripherals. A large 
portion of these resources are interconnected using 
NSC's HYPERchannel network. The configuration 
flexibility afforded by HYPERchannel provides HOSC with 
the ability to adapt to future mission requirements and 
also provides MSFC with a large computing facility for 
non-mission activities. 

Data handling at HOSC rails into two main 
categories, mission and non-mission activities. Mission 


2 


activities are those that take place during powered 
•flight. For example, the space shuttle main engine data 
is analyzed by the Main Propulsion System (MPS) 
processor, which is also sent to a back up processor 
simultaneously. Data arrives via direct ground links or 
satellite communication links from the Kennedy Space 
Center Firing Room at NASA's Kennedy Space Center (KSC) 
in Florida or from NASA's Johnson Space Center (JSC) in 
Texas. Services provided by the network during missions 
are data analysis and presentation services for HOSC 
mission support teams. Non-mission activities are also 
provided b: HOSC, one of these is support for the 
Payload Operations Control Center (POCC) preplanning 
activity. Future expansion at HOSC may include computer 
resource support for Digital Equipment Corporation's 
interactive graphics data base (IGDS), and XEROX 
Corporation's text-processing operation 'SIGMA), both 
of which, are non-mission activities. 

1.3 Research Objective 

NSC's HYPERchannel local area network is a 
sophisticated computer network allowing considerable 
flexibility and adaptability with regard to computer 
resources. HYPERchannel allows a wide variety of 
minicomputers, not necessarily manufactured by the same 
company, to be interconnected in a single or 
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multi-trunk network. Thus, computer resources which may 
be separated by distance or manufacture^ may be 
utilized by one another within this distributed 
computer network. HOSC , as a distributed computing 
■facility, utilizes HYPERchannel to accomplish the 
interconnection of various computer resources. Mission 
requirements imposed on the HOSC, require that it 
possess the ability to adapt and change its resources 
according to the dictates of a particular mission. The 
configuration of the HOSC's resources are mission 
dependent and may be readily changed, however, the 
effects of those changes cn system performance are not 
readily apparent. The data handling capability of the 
HYPERchannel network and its performance in various 
configurations affect HOSC's system performance 
directly. With this in mind, the primary goal of the 
research effort was the development of a simulation 
model of the HYPERchannel network that could be 
manipulated to predict and characterize the behavior of 
the HOSC in a variety of scenarios. 

The first step in this analysis was an 
investigation of the operating properties and 
characteristics of a HYPERchannel network. In Chapter 2 
of this Document, a functional description f 
HYPERchannel is detailed with particular emphasis on 
the protocols used by the network. The second step, 
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detailed in Chapter 3, was the characterization of 
various computer resources and possible HOSC activity 
scenarios. The third step, detailed in Chapter 4, was 
the definition and development of a software model of a 
HYPERchannel network. Using this simulation node 1 , 
system parameters were varied to simulate changes to 
the operating environment of the HOSC. Finally, the 
results and conclusions of these manipulations to the 
simulation model were compiled and analyzed in order to 
provide some insight into the present and perhaps 
future operating characteristics of the HOSC. 
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Chapter 2 

HYPERchannel Network Description 


2.1 Network Components 

Network Systems Corporation's (NSC) HYPERchannel 
network is a high speed, baseband local area network. A 
HYPERchannel network consists o f standard Community 
Area Television (CAW) coaxial cables used as data 
trunks and various adapters to control network traffic 
■flow. These adapters use a carrier sense multiple 
access (CSMA) protocol with prioritized, staggered 

| 

delays to implement tra-f-fic -flow and control. Network 
messages generated by an adapter are composed of -frames 
and are called frame sequences. These messages are 
broadcast over a given trunk at a fixed rate of 50 
Megabits per second, using a phase modulation technique 
with a manchester data format, and are received by 
network components through nond i rec t i onal taps or ports 
(Figure 2.1). Network components at. these ports are 
known as network adapters, which control access to a 
given trunk. A network adapter can be attached to as 
many as four independent network trunks, enabl i ng a 
configuration to match a specific installation and 
provide: 

o incremental expansion 
o linear interconnect cost 
o no single point of failure 

6 
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NSC manufactures three main types of network 
adapters: processor, device and link. A processor 

adapter interfaces a computer data channel to the 
network of data trunks. It serves as buffered data path 
between the computer attached, and the trunk network. 
The computer communicates with data buffers in the 
adapter at its own rate and asynchronous with 
transmissions on the network trunks. The adapter 
provides the necessary formatting and internal protocol 
to transmit the contents of its buffers over the 
selected network trunk. The processor adapter receives 
data from the trunk network and provides status 
information to the originator of the data. The computer 
at the receiving adapter may then access the data and 
any associated message in the adapter buffer. NSC has 
designated this adapter type as A400 HYPERchannel 
adapters, herein referred to as adapters. The device 
adapter functions as a remote channel providing a 
computer data channel for the attachment cf peripheral 
contro’ units. This adapter is driven b> network 
messages from the data trunks. It receives network 
messages containing device commands, data, and control 
information. It oenerates messages containing status or 
device data. The device adapter operates multiple 
devices in the same manner as a data channel produced 
by a computer manufacturer operates multiple devices. 
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The link adapter is used in pairs to provide 
communication between remote HYPERchannel networks. A 
link adapter receiving a network message destined -for a 
remote network transmits this message over a wide band 
communications link to the remote network. The link 
adapter at the remote location receives this message 
and retransmits it over its own local network. There 
are two types o-f link adapters, the terrestrial link 
adapter and the satellite link adapter. 

Finally, due lo the nature o-f the HOSC computing 
•facility only the processor adapter will be included in 
the mode 1 . 

2.1.1 Adapter Architecture 

Each adapter, regardless o-f the type o-f user 
equipment attached, consists o-f the -following: 

o A 16-bit m i cr 3-p 'ocessor with 4096 

words o-f read-only memory <ROM) 

o Storage section (Bu-f-fer and Control logic) 

1024 3-bit bytes o-f control memory with 
odd par i ty 

4096 8-bit bytes o-f bu-f-fer memory with 
odd p ar i ty 

1 6 working registers 
16 trunk registers 
256 extension registers 

o One trunk inter-face 

This portion o-f an adapter is termed the Nucleus 
Adapter. The nucleus adapter has two general 


app 1 i cat i ons ,( processor and device adapter) determined 
by the type of equipment attached and the necessary 
interface required. Thus an adapter consists of a 
specific device interface and a nucleus adapter. The 
device interface will then define the particular 
adapter type. An adapter can be divided into four main 
sections: micro-processor, buffer, and control logic, 

trunk interface, and devic-? or equipment interfare 
(Figure 2.2). The micro-processor has a 4096 16-bit 
word read-only instruction memory with a 320 nanosecond 
cycle time. It handles equipment functions and 
responses arid manages data flow on the direct data path 


be twe 

the 

equ i pmen t 

and 

the edapte*' buffers. The 

buffer 

and 

control 

logic 

along wth the trunk 


interfaces control the high speed trunk transmissions. 
It consists of a 1024 8-bit byte control buffer, 
normally used to stack control information, and a data 
buffer containing ^096 or (optionally) 8192 8-bit 
bytes. This section also contains a flag register and 
other registers to specify buffer address, length of 
data tran mission, and network addressing functions. 
The control logic contained in this section allow 
concurrent access to memory by both trunk interfaces 
and equipment interfaces. The 100 Mbps buffers allow a 
50 Mbps data movement on the data trunks along with a 
50 Mbps data movement with the attached equipment. The 
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trunk inter-face board (up to four) contains the 
necessary transmitting and receiving electronics and 
the high speed logic to control the transmission 
enve 1 ope-checkwor ds , access code, and network address. 
Each trunk interface has the ability to generate a busy 
or reserved response and contains the logic to control 
trunk contention on its attached data trunk. Finally, 
the device interface (up to four) or equipment 

interface contains the circuitry needed to interface a 
specific equipment or device to the adapter. This 
interface is unique to a given device and determines 
the adapter type. 

2.2 HYPERchannel Protocols 

HYPERchannel adapters support trunk selection, 
trunk-access, adap ter-adap ter virtual circuit, and 
host-adapter protocols. The trunk selection protocol is 
based cn a cyclic scan of the connected data trunks. 
The trunk-access protocol is of the carrier sense 
multiple access (CSMA) type, with ordered priorities 
assigned to each adapter. The adapter-adapter virtual 
circuit protocol involves connection (adapter 
reservation and deadlock avoidance) and data flow 
control. The assumption of a steady state model 
precludes inclusion of the host-adapter protocol since 
a host is represented as a fixed rate data source. In 
order to understand the impact of the various protocols 
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on system perf ormance , they will be described in detail 
in the remainder of this section. 

2.2.1 Trunk Access Protocol 

HYPERchannel uses a carrier sense multiple access 
scheme with prioritized staggered delays to implement a 
trunk access protocol. The intention of this scheme is 
to : 

o ensure that ready adapters defer to on- 
going transmissions 

o ensure that .'espor.se (acknowledgement) 
frames are transmitted without inter- 
ference 

o provide as much trunk capacity to the 
highest priority adapter as it requests 
by prioritized access, and provide as 
much capacity to the next highest priority 
adapter as it requests, and so on 

o sort out collisions without the necessity 

of generating random retry delays and ensuring 
that colliding frames are not involved in 
collisions when retransmitted. 

HYPERchannel accomplishes this with four primary 
mechanisms: transmitter disable, fixed delay, N delay 

or pr i or i ty delay, and end de 1 a> . These functions are 
implemented on each trunk interface board and can be 
different for each trunk attached. 

Any time the trunk is sensed busy the adapter 
transmitter is disabled (unless it is transmitting) so 
that an ongoing transmission will not be interfered 
with. The fixed delay period is a de 1 a> period 
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following any transmi s i on in which only the receiving 
adapter -for the last transmission is allowed to 
transmit. This period of time allows a receiving 

adapter to respond immediately without being interfered 
with by other ready "sending adapters". A transmitting 
adapter which does not receive a response to a 

transmission during this period assumes that its last 
transmission was lost and will schedule a 

retransmission. Following the fixed delay period a 
scheduling period begins. This period is the N delay or 
Priority delay period and is a unique event for each 
adapter on a given trunk. An adapter's priority delay 
is assigned based on the priority (user defined) and 
placement on the trunk of the adapter in question. 

Following the fixed delay period an adapter ready to 
transmit will wait until its priority delay, at which 
time it is allowed to transmit without interference if 


the trunk is 

idle. If an 

adapter becomes 

ready 

to 

transmi t 

during 

this schedu 1 

i ng 

period, but 

after 

i ts 

priori ty 

de 1 ay 

has expired 

i t 

must wa i t 

until 

i ts 

priori ty 

de 1 ay 

occurs again 

or 

until the 

end de i ay 


period (defined next) is encountered. The end delay 
period occurs if an entire scheduling period passes 
without an adapter transmission. After this event a 
free-for-all or contention period begins in which any 
adapter which becomes ready to transmit may do so. In 
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this contention period, collisions become possible if 
two adapters sense the t.'unk idle and attempt to 
transmit nearly simultaneously. These various delay 
events are implemented in each adapter by a timer. This 
timer is enabled any time the trunk is sensed idle and 
begins to count down to its respective delay events. If 
at any time the trunk is sensed busy the timer is 
disabled and loaded with the end delay value. As the 
timer counts down the fixed delay, pr i or i ty delay, and 
the end delay events are signaled (Figure 2.3). 

These delay settings are set into what NSC terms 
as contention switches (SW1-SW9), located on each trunk 
interface board. These contention switches have 16 
discrete positions (0 through F'< , with each position 
providing 160 nanoseconds of delay. Tht-se switches are 
grouped in sets of three switches per parameter. SW1 , 
SW2 and SW3 are the least-significant bit position 
switches and SW7 , SW8 and SUJ9 are the most-significant 
bit position switches. An adapter's fixed delay >s set 
into switches <SW7, SUM and SW1), its priority delay is 
set into switches (SUJ8, SW5 and SW2) and finally, its 
end delay is set into switches (SU"’, SUJ6 and SW3) . The 
actual settings for these switches are calculated from 


expressi ons 

given 

by NSC. 

These 

expressi ons 

when 

eval uated, 

yield 

decimal 

numbers 

which are 

then 
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Figure 2.3 HYPERchannel Delay Time Event 



converted to hexadec i mal equivalents. The hexadec i mal 
equivalents are then set into the contention switches. 

When an adapter receives a transmission -frame it 
will immediately generate and transmit a response 
■frame. So that all ready-to-send adapters will not 
inter-fere with this response, the fixed delay period 
must be such that all adapters will sense the response 
before this delay expires. This relation as given by 
NSC [NSC80a] is: 


Total trunk cable 

Fixed Delay = 1 enoth < f t . > + 13 <1) 

40 

This value as calculated will be the same for all 
adapters on a given trunk. The priority delay refers to 
the period of time uniquely assigned to each adapter on 
a trunk. This time period occurs following the fixed 
delay period and is determined by the adapter's 
assigned priority and position on the trunk. The 
highest priority adapter is assigned a priority delay 
of 0.48 microseconds, this allows sufficient time for 
the highest priority adapter to prepare to retransmit 
an unacknowl edgea frame prior to its scheduled 


transmission time. 


The priority delays -f or the remaining adapters on the 
trunk is given by [NSC80a3: 


Priority delay o-f next 

Priority = 10 ♦ highest adapter (decimal value) 

De 1 ay 

( 2 ) 

♦ Cable length (ft.) to next highest 

priority adap ter 

40 

NSC recommends that priorities should be assigned 
sequentially in order ♦■o maximize throughput on the 
trunk. The end delay is calculated -for each adapter 
such that the lowest priority adapter on making a 
transmission is sensed by all other adapters on the 
trunk. This is necessary since an adapter may transmit 
immediately when its end delay is signaled (contention 
period). This ue 1 ay is calculated as -follows CNSCSOa]} 


end Delay = 10 ♦ 


♦ 


Priority delay o-f lowest 
priority adapter (oecimal value) 

(3) 

Cable length (-ft.) -from this 
adapter to farthest adapter 
40 


An example o-f the use o-f (1>i (2) and (3) is 

illustrated in Figure 2.4. The calculations which 
■follow are per-formed -for unit #25, trunk 0. 
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Fixed delay = 1200 feet + 13 = 43 jq = 26 1<;> 

40 

Priority delay = 10 ♦ 3 + 400 = 23 10 = 17 16 

40 

End delay = 10 + 63 jq ♦ 800 = 93jq = 

40 

These values are then set into the contention switches 
located on the AD8 trunk inter-face board as indicated. 
Finally, in the access scheme described thus -far, the 
highest priority adapters could possibly monopolize the 
trunk. To prevent this a device known as a wait 
■fl ip— -flop is implemented in each adapter. This 

-flip-flop is set when an adapter transmits and is 
cleared when the adapter end delay is signaled. When 
the flip-flop is set the adapter is prohibited from 
transmitting, the intention of this device is to 
provide a fair allocation of the trunk. All adapters 
are equipped with this device and adapters with this 
flip-flop enabled may coexist, on the same trunk, with 
adapters whose flip-flop is disabled. 

2.2.2 Adapter-Adapter Link Level and Virtual Circuit 
Protocol s 

The following sections will deal with data 
movement and the protocols involved once an adapter has 
gained access to the trunk through the trunk access 
protocol . The data 1 ink protocol may be viewed as 
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having two basic information grouping levels. The basic 
information unit is the frame and a higher level 
grouping is the frame sequence. 

2.2.2. 1 Frame and Frame Sequence Structure 

The smallest unit of information transmitted over 
the network is the frame. There are three classes of 
frames: transmission frames, data frames, and response 
frames. Transmission frames are generally short frames 
(up to 38 bytes) used by adapters for signalling and 
status exchanges. Table 2.1 lists these frames and 
their functions. There are two forms of data frames, 
message proper frames and associated data frames 
following a message proper frame (Figure 2.8). An 
adapter receiving a transmission frame, message proper 
or a data frame will generate and transmit a response 
frame. This response frame serves to acknowledge 
receipt of a frame and in some cases returns 
information to the transmitting adapter. Frame formats 
are listed in Table 2.2. Note from Figure 2.8, that the 
fixed delay period is used to initiate transmission of 
other than acknowledgement frames as will be explained. 

As stated previously, a higher level information 
structure is achieved by grouping frames together into 
frame sequences. All information exchanges occurring on 
the network will be in the form of frame sequences. 
There are two types of frame sequences used on the 
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Table 2.1 HYPERchannel Protocol Frames [Fran 84] 


Transmission Frames 


Set Reserve 
Copy Register 
Cl ear FI ag 8 


Set Flag A 
Clear FI ag A 


Cl ear FI ag 9 


- Reserve receiving adapter 

- Request for Register in-formation 

- When set, Flag 8 indicates that 
the adapter is ready to receive a 
■frame. When clear, it indicates 
that the frame has been received. 

- Flag A, when sat, indicates that 
the receiver will receive 
associated data. It is cleared 
when the last block of associated 
data is rece i ved . 

- When set in the receiver, Flag 9 
indicates that the receiver is 
ready to receive data. When set 
in the transmitter, it indicates 
that the transmitter is ready to 
send data. When cleared in re- 
ceiver, it indicates that the 
data block has been received. 

When cleared in the transmitter, 
it indicates that data can now bs 
tr ansm i t ted . 


Data and Messaoe Frames 

Message Proper - Used to transmit host messages of 

length less than or equal to 64 
bytes . 

Associated Data - Used to transmit data blocks of 

length up to 2 Kbytes. 

Response Frames 


Response - A receiving adapter sends a re- 

sponse frame for each non- 
response frame received. Its pur- 
pose is to acknowledge received 
frames or, as in the case of the 
response to a copy registers 
frame, to send requested data. 
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Table 2.2 Frame Formats [FRAN82] 


Field 

Length 

(bytes) 

leading syncs . 

. 12-18 

■frame type . . 

. 1 

access code . . 

. 2 

to address . . 

. 1 

*rom address 

. 1 

■function code . 

. 2 

message 1 ength 

. 2 

check word . . 

. 2 

tr a i 1 i ng sync . 

. 8 


Field 

Length 

(bytes) 

leading syncs . 

. . 3 

■frame type . . 

. . 1 

access code . . 

. . 2 

to address . . 

. . 1 

■from address 

. . 1 

■function code . 

. . 2 

message 1 ength 

. . 2 

check word . . 

. . 2 

trailing . . . 

. . 8 


Transmission Frame Format 


Response Frame Format 
(no data) 


Field 

Length 

(bytes) 

leading syncs 

. .12-18 

frame type 

. . 1 

access code . 

. . 2 

to address 

. . 1 

from address 

. . 1 

function code 

. . 2 

message length 

. 2 

check word 

. . 2 

message/data 

. .8-64/ 

message/data 
checkword . . 

0-2K 
. . 2 

cr a i 1 i ng sync 

. . 8 


Field 

Length 

(bytes) 

leading syncs 

. . 3 

frame type 

. . 1 

access code . 

. . 2 

to address 

. . 1 

from address 

. . 1 

function code 

. . 2 

message 1 ength 

. 2 

check word 

. . 2 

regi ster 


i nf ormat i on . 

. . 2 

checkword . . 

. . 2 

trailing sync 

. . 8 


Message Proper and Associated 
Data Frame Format 


Response Frame Format 
(with data) 


V 













network: message-only and message-wi th-data sequences. 
A message-only sequence is normally used to transmit 
short messages of up to 44 bytes between devices on the 
network. The sequence o-f -frames which make up a 
message-only sequence are shown in Figures 2.5 and 2.6. 
Data is transmitted on the network in 2K byte blocks 
(optionally 4K byte blocks) in message-w i th-data frame 
sequences, as shown in Figures 2.7 and 2.8. 

In order to promote efficient utilization of the 
trunk an adapter does not maintain control of the trunk 
throughout an entire message-only or message-w i th-dat a 
sequence. An adapter will relinquish the trunk while 
performing tasks not requiring the trunk, these periods 
are depicted as delays in the Figures representing the 
two types of message sequences. After transmitting the 
first frame of a sequence the trunk is released. When 
the transmitting adapter is ready to continue 
transmitting it must compete with the other adapters 
for trunk access. After regaining access to the trunk 
the adapter will transmit a copy register frame, if 
this frame is transmitted without a collision, the 
receiving adapter will send a response frame to the 
sender. Upon receipt of a response frame the adapter 
captures the trunk by transmitting during the fixed 
delay period that follows. The trunk is regained 
without interference since any ready to send adapter is 
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SENDER 


RECEIVER 


Set Reserve 


Copy Registers 


Message Proper 


Clear Flag 8 








Re sponse 


Response 

regi ster 

— Response 

— Response 


< Includes 
i nforma t i on ) 


Note: Frames enclosed within bracket are transmitted without 
interference by beginning their transmission in the fixed 
de lay per i od . 


Figure 2.5 Message-Only Frame Sequence [ FRAN84 ] . 
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prevented from transmitting during the fixed delay 
period. If the sequence to be transmitted is a 
message-only sequence, control of the trunk is not 
relinquished until the entire remaining sequence is 
transmitted, see Figure 2.6. The timing and duration of 
a message-only sequence is shown in Figure 2.6. 

A message-wi th-data sequence is preceded by a 
message-only sequence, following the transmission of 
the message proper the trunk is released, see Figure 
2.7. When the receiver indicates that it is reaay to 
receive more data by sending a clear flag 9 frame to 
the sender, the sender will compete to regain access to 
the trunk. Once the sender regains access to the trunk 
it will send a copy register frame to the receiver. If 
successful, it will regain control o* the trunk as 
described before. Control of the trunk will not be 
relinquished until an associated data frame and clear 
flag 9 frame are transmitted by the sender. This 
process is repeated for each associated block of data. 
Maintaining control of the trunk during data frame 
transmissions ensures that these frames are never 
involved in collisions, thus only relatively short 
frames will ever need r e tr ansm i ss i on due to collision 
on the trunk. The trunk is held during data frame 
transmission by the sending adapter, by transmitting 
synchronization bits during the fixed delay periods 
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•following the transmission -frames that make up the data 
•frame sequence. The timing and duration o-f this 


sequence of 

frames 

i s 

shown 

i n 

Figure 

2.8. It is 

important to 

note 

that 

i n 

al 1 

of these sequence 

tr ansm i ss i ons 

that 

dur i ng 

the 

de 1 ay 

periods, a 


transmitting adapter must al ways compete for trunk 
access in order to regain the trunk. 

NSC adapters also support an alternate -form o-f 
transmission scheme known as the burst mode. In this 
•form o-f sequence transmission, an adapter will not 
relinquish the trunk until it completes an entire -frame 
sequence transmission. According to literature 
available [ FRAN823 , t FRAN84 ] this mode is rarely used 
and will not be detailed in this work. 

2. 2. 2. 2 Trunk Selection 

Any adapter in a network can be connected to up to 
•four trunks. Each trunk uses the same trunk access 
protocol and operates independently, i.e., each trunk 
has a separate inter-face board within an adapter. The 
inter-face listens -for properly addressed incoming 
messages and is capable o-f generating rejection 
response -frames i -f its adapter is reserved. An adapter, 
having a frame to transmit and contending for a trunk 
will scan the trunks in a specified manner until it 
senses a non-busy trunk. The adapter then waits until 
the trunk can be captured through the trunk access 
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protocol. It the trunk is busy with the adapter's frame 
transmission its search terminates; otherwise it 
continues. Trunks to be t.-.ed c*; oe spec i :• c in i 
host-adapter message and a receiver's trunks to try may 
be specified by the transmitting adapter. A trunk is 
said to be disabled if it is not connected or was not 
specified as a trunk to try. A •■runk is said to be 
enabled if it is connected or is specified as a trunk 
to try. An adapter will try a trunk by first 

determining whether it is enabled or disabled, if the 
trunk is disabled or busy it will try the next trunk. 
If the trunk is enabled then the adapter determines 
whether or not it is busy. The period of time required 
to try an enabled trunk is 5.5 microseconds, while the 
time required to try a disabled trunk is 2 
microseconds. The ability to specify the trunks to try 
in the transmitter and receiver provides a means to 
dedicate trunks to specific types of traffic, e.g., 
short transmissions on one, long tr ensrn i ss i ans on 
another. Simulation stud'es indicate no benefit is 
derived from dedicating trunks for particular message 
types. The ability to specify trunks is more useful in 
multitrunk networks that are not fully connected 
[FRAN343. It is possible for an adapter connected to 
more than one trunk to receie messages simultaneously, 
when this happens the adapter will accept one and 


reject the others. Communication between adapters on 
two different trunks, requires the services o f an 
i n termed i ar y . One of the adapters will transmit to a 
device attached to an adapter common to both trunks. 
Once this device has received this message sequence it 
will then proceed to transmit the sequence to the 
intended receiver on the other trunk. Thus 
communication between adapters on different trunks 
consists of sending a message-wi th-data sequence twice. 
2 . 2 . 2. 3 Virtual Circuit Establishment 

An adapter reservation scheme (Figure 2.9) is used 
to establish a virtual connection between adapters 
desiring to communicate. When an adapter receives a. 
message from its attached host, it will first reserve 
itself; that is, the adapter makes itself inaccessible 
to received transmissions from any other adapter with 
the exception of the adapter with which it is trying tc 
communicate. After reserving itself, the sending 
adapter transmits a set reserve frame to the receiving 
adapter. If the receiving adapter is idle; that is, it 
is not reserved, then the receiving adapter will 
transmit a response frame indicating that the adapter 
has reserved itself to receive a transmission from the 
transmitting adapter. Following the reservation of the 
receiver, the frame sequence transmission proceeds as 
described in section 2. 2. 2.1. Both the transmitting and 














receiving adapters remain reserved during the entire 
message-only or message -w ; th-dat a -frame sequence 


transmission. After completing the -frame sequence 
transmission, the transmitting adapter releases the 
receiving adapter with a clear -f i ag A -frame and then 
releases itself completing the termination of the 
connection; see Figures 2.6 and 2.8. 

When a transmitting adapter sends a set reserve 
frame to a reserved adapter, the reserved adapter will 
respond with a reservation reject frame. The first t i mo 
a sending adapter receives a reservation reject frame, 
the adapter will delay for a "binary exponential time" 
before making another reservation attempt. Following 
the first reservation rejection the adapter will delay 
1 microsecond before making a second attempt. For each 
following reservation rejection, the adapter will delay 
an amount of time equal to twice the previous delay, up 
to 128 microseconds. When this value of delay (128 
microseconds) is exceeded retry is advanced by one, the 
delay is reinitialized, and the sequence is repeated 
(Figure 2.9). This process will continue until either a 
successful reservation occurs or the adapter's retry 
count is exceeded. An adapter's retry count is based on 
its unit number, manually set by the user and is in the 


range of 

55 

to 250. 

If 

after retry 

count 

tries 

the 

adap ter 

i s 

unable 

to 

reserve the 

rece 

i v e r , 

the 


transmission is aborted ana the sender returns to the 


idle state. The sending adapter remains reserved 
throughout the entire reservation attempt process. This 
reservation scheme with the binary exponential delays 
between transmissions, serves as congestion control on 
the network by keeping a sending adapter -from 
monopolizing the network. 

This retry scheme as described has the potential 
of causing adapter deadlock. This will occur i f two 
adapters attempt to reserve each other nearly 

simultaneously. They will find each other reserved and 
go through the retry scheme until one or the other's 
retry count is exceeded and aborts the attempted 
transmission. To alleviate this problem, a back -off 
scheme is employed by communicating adapters. This 
back-off routine enable* a sending adapter to determine 
the identity of the adapter that the rejecting adapter 
is attempting to reserve from the •'eject response. If 
the sending adapter determines that it and the 
rejecting adapter are attempting to reserve one 
another, then the sending adapter aborts its 
reservation attempt ard releases itself. The slowness 
of this back-off mechanism can cause both adapters to 
abort their reservation attempts, preventing either 
adapter from communicating on the network. The time 
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required for this mechanism to respond is dependent on 
the adapter model and is approximately 50 microseconds. 

A second form of deadlock which the back-off 
mechanism will not correct is called a reservation 
request loop. This occurs when three or more adapters 
attempt to reserve each other, i.e., adapter A attempts 
to reserve adapter B, vh i 1 e B attempts to reserve C, 
and C attempts to r^i.-^ve A. In this case the adapters 
have no way o-f determining that this situation exists 
and each adapter wit per -form the reservation retry 
scheme as previously described. This deadlock will only 
be resolved ,vh r one of the adapter's retry count 
expires, causing the adapter to abort its reservation 
attempt and release itself. Serious degradafion cf 
trunk throughput max be predicted during this 
reservat i on request loop period CDONN793. 

2. 2. 2. 4 Data Flow Control 

Network adapter's are supplied with two 2K byte 
buffers <4K byte buffers optional). With two buffers 
one can be f i 1 1 ed/emp t i ed by transfer from/ to the 
attached host, while the other buffer is emptied/filled 
by a network transmission/reception. In order to ensure 
that buffer capacity is not exceeded, a flow control 
mechanism is needed. Flow control is achieved in two 
ways. First, data frame length is limited to adapter 
buffer length. Second, an adapter sending a data frame 
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may not send another data -frame until the receiving 
adapter specifically requests it. This ensures that an 
adapter will not receive data -frames at a rate -faster 
than an adapter may process them. 

Additional techniques used by adapters to prevent 
them -from becoming permanently blocked awaiting receipt 
of a response frame which will never arrive are 
described in the following. One of the techniques 
involved is the requirement that response frames begin 
their transmission during the fixed delay period. If an 
adapter does not receive a response to a transmission 
it will reschedule the transmission at a later time. To 
ensure that an adapter does not retransmit 

indefinitely, as would be the case if the receiver 
address were incorrect or the receiver was 
malfunctioning, a limit is placed on the number of 
retransmissions allowed. A set reserve frame will be 
transmitted 14 times on each trunk and then aborted if 
no response is received. All other frames will be 
transmitted 254 tines before abort, For the case when 
the expected response is a non-response frame < clear 
flag 9 granting permission to transmit data) a "deaaman 
timer" is used. In a transmitting adapter this time 
frame spans the time from when the host's transmit 
message is received until the last buffer is 


transmitted and acknowledged. In the receiving adapter 


this time begins with the receipt of a set reserve 
■frame and does not end until the receipt o-f the last 
data bu-f-fer. This time span ranges -from .5 to 8 
seconds, adjustable in .5 second increments. If all 
frame transmissions are not completed before this timer 
expires, the transmission is aborted [FRAN82I. 

2.3 Intra-Adapter Communication 

A message transfer between attached hosts on the 
same adapter is termed an i n tra-adap ter transfer and is 
carried out entirely local to the adapter. This type of 
data transfer occurs without utilizing the data trunk 
network. An important consequence of this type of 
transfer is that the adapter will appear reserved to 
the rest of the network. Obviously, if the occurrence 
of this type of transfer becomes predominate then 
network performance will suffer. If resources do not 
conflict, intra-adapter communication may occur 
concurrently with network traffic and cause no 
degradation of network performance. 
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Chapter 3 

HOSC System Description 


As previously stated, HOSC is a distributed 
computer network employing many large m i n i -compu t er s 
and NSC's HYPERchanne 1 network. The primary task c-f 
HOSC is to provide NASA scientists and engineers with 
near real time acquisition and analysis o-f data during 
Space Shuttle operations. This in-formation allows MSFC 
engineers and contractor personnel to act in a support 
capacity to other mission specialists at KSC and JSC. 
Some o-f the primary monitoring and support requirements 
o-f HOSC are pre-launch support -for the Space Shuttle 
Main Engine <SSME>, the Externa' Tanks (ET>, the Solid 
Rocket Boosters (SRB's), the Main Propulsion System 
(MPS) , ana the Range Sa-fety System <RSS). Further, 
supoort is provided -for mission experiments designed by 
MSFC per sonne 1 . 

NASA has de-f i ned the mission o-f the Flight 
Operations Support Center at HOSC as -follows: 

During powered -flight, the HOSC will 
receive only data which is in the LPS (Launch 
Processing System) at KSC. The Shuttle 
support team will be in the HOSC during this 
phase o-f the mission and will be the point o-f 
contact with the JSC Mission Evaluation Room 
(MER) -for problem discussion and resolution 
as required and will be on call during 
orbital operations. The Space Lab and 
experiment support team will be located in 
the HOSC during orbital operations when 
app 1 i cabl e . 




Following completion of the active 
Shuttle vehicle support activities, data is 
recalled as required -for more detailed 
analysis, and initial preparation is made to 
provide support to post -flight evaluation 
CNASA823 . 

HOSC is located in the west end o-f A-wing building 
4663, at MSFC in Huntsville, Alabama. Figure 3.1 shows 
the -functional components o-f one o-f many HOSC system 
configurations. The information contained in the 

following sections of Chapter 3, is from previous work 
published in connection with this same research effort 
[MAUL843 . 

3.1 Typical HOSC System Activities 

The data processing activities at HOSC can be 
placed into two categories, routine daily activities 
and mi ss i cn/1 aunch activities. A summary of these 
activities by category and some details of typical data 
transfers are outlined in Table 3.1. While this table 
and the description that follows describe typical 
activities, these are not all the activities that HOSC 
is engaged in. There are some activities that are 
defined only for a current m i ss i on , i . e . , experiments 
directed by HOSC mission specialists. Since these may 
change from mission to mission they are not included in 
the following description, but must be characterized 
and considered in the specific mission scenario 
required for the total system analysis. 
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Figure 3.1 Typical HOSC Configuration. 













TABLE 3.1 HOSC Data Transfers 


O' 


I. ROUTINE DAILY ACTIVITIES 

A . POCC Ac t i v i ty 

Resources Involved: MRS Primary (VAX 4^ 

MPS Backup (VAX 1) 

Quantity of Data: 150,000 512-byte blocks in 

two components. 6 8344-byte 
blocks and 100,000 512-byte 
bl ocks . 

B. ECIO Data Stream (Generated by POCC) 

Resources Involved: MPS Backup (VAX 1) 

Space lab 8/32 

Quantity of Data: 51.2 kilobyte per second 

stream concurrent with POCC. 

C. IGDS/SIGMA Activities (Proposed) 

Resources Involved: To be determined 

Quantity o-f Data: Unknown. 

II. ROUTINE LAUNCH ACTIVITIES 

A. Routine Daily Activities (See I tern I.) 

B. Main Engine Data 

Resources Involved: STS Primary (PE 3244) 

MPS Backup (VAX 1) 

Quantity of Data: 50 kilobit per second stream 

(Launch minus 8 hours until 
MECO) 

C. OD Data Stream 

Resources Involved: FEP SSME (PE 3244) 

CSO Computer 

STS Primary (PE 3244) 

MPS Backup (VAX 1) 

Quantity o-f Data: 192 kilobit per second 

stream into FEP and then to 

CSO with transfer r+ 40 
percent to STS Primary and 
MPS Backup. (Launch minus 9 
seconds until MECO) 

D. Engineering Display Changes 

Resources Involved: STS Primary (PE 3244) 

STS Backup (PE 8/32) 

Space lab 8/32 (PE 8/32) 

Quantity o-f Data: Insignificant. 
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One activity not associated directly with the 


real-time responsibilities of the network and therefore 
a routine daily activity is POCC simulation activity. 
The impact of POCC activity on overall performance of 
the network stems from the requirement of continuous 
data transfers between network computers. This data is 
currently being transferred between the MPS primary 
computer (VAX 4> and the MPS backup computer (VAX 1). 
During each twen ty-f our-hour period, this activity 
requires the transfer of 150,000 512-byte blocks of 
data. This data is transferred in two components; six 
times each day, an 8344-byte block is transferred 
(50,000 bytes cumulative), with another 100,000 

512-byte blocks transmitted randomly but distributed 
evenly throughout the day. 

POCC also generates a continual 51.2 kilobit per 
second data stream known as the Experiment Computer 
I npu t/Ou tpu t (ECIO) data stream. This data stream is 
ongoing and concurrent with POCC activity. ECIO data is 
transferred from the MPS Backup Computer (VAX 1) to the 
Space! ab 8/32 (PE 8/32c>. 

The routine components of the launch day data 
activities ar? the Main Engine Data Stream, the 
Operational Data (0D> Stream, ar.d the Engineering 
Display Change requests. The Main Engine Data is 
collected and disseminated on launch day only. Data is 
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funne’ed through the network to the MRS Backup Computer 
(UAX l) -from the Shuttle Transport System (STS) 
Computer (PE 3244). From eight hours before launch 
until about twelve minutes after launch at Main Engine 
:ut Off (MECO) , STS Primary accepts a continuous 50 
kilobit per second lata stream directly from the KSC 
Firing Room and transfers about 24 percent (12 kilobits 
per second) of the total stream to MPS Backup. 

The 0D Stream is a 192 kilobit per- second data 
stream arriving at the Front End Processor Space 
Shuttle Main Engine <FEP SSME) Computer (PE 3244) on 
launch day concurrently with some of the Main Engine 
Data (launch minus 9 seconds until MECO). This data 
arrives from Goddard Space Flignt Center in Maryland, 
and is transferred over the network to the CSO 
f ac i 1 i ty . 

The Engineering Display Change activity is an 
almost insignificant addition to the total network 
traffic. This activity involves a transfer from STS 
Primary to STS Backup and Spacelab 8/32. This transfer 
consists of the name of each engineering console format 
in the support facility that is changed during the 
prelaunch and launch period (launch minus 9 seconds to 
MECO) [MAUL84 ] . 
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3.2 HOSC System Components 

The Huntsville Operations Support Center as a 
distributed computer -facility uses various computer 
resources interconnected together. The basic components 
involved at HOSC are the computers, communications 
processors that receive data from wideband 
communications links (satellite and terrestrial) and 
the hardware recuired to interconnect these various 
resources. The interconnecting hardware, Network 
Systems Cor por a t i on ' s HYPERchannel network, has been 
previously described, and interconnects a variety of 
computer resources of different manufacture, i.e , 
Digital Equipment Corporation (DEC), Perkin-Elmer (Ph), 


and UNI VAC. 

The bulk 

of the proces 

sing 

power 

for 

the 

ne twork i s 

performed 

by the 

DEC 

VAX 

and 

PE 

3240 

c omp u t e r s . 

A cursory 

1 ook will 

be 

given 

to these 

two 


computers. These computers are examined for the sake of 
information only, since in the subsequent analysis all 
network users will be represented as fixed rate data 
generators . 

The Digital Equipment Corporit ion's VAX series of 
computers supports a 32-bit word architecture that 
establishes a virtual address space of 4.3 billion 
bytes of user-addressable memory. Throughput of data in 
the system is optimized by using a 32-bit high speed 
data structure that ties together the central 
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processor, main memory, UNIBUS subsystem, MAESBUS 
subsystem and the DR780 high speed direct memory access 
subsystem. This high speed data structure is known as 
the Synchronous Backplane Inter-face (SBI) and a device 
linked to it is known as a NEXUS. Each NEXUS receives 
every SEI transfer; electronic logic in the NEXUS 
determines whether it is the designated receiver -for 
the ongoing trans-fer. Data transfers can occur from CPU 
to memory, from I/O controller to memory subsystem, or 
from CPU to I/O controller, with maximum aggregate 
transfer rates of 13.3 megabytes per second. These 
transfer rates are limited by the following factors: 

o 2G0 nanoseconds/cycle = 5 million cycles 
per second 

o each cycle can carry an entire byte of 
data or address representing a memory 

request 

o one cycle is used to request eight bytes 
of data to be read or written, and two 
cycles are used to carry data at four 
bytes per cycle 

o 5 million cycles/second * 4 bytes/cycle = 

20 million by t*»s/second 

o 20 * 2/3 <1 of every 3 cycles is an 

address) = 13.3 million bytes per second 
[DEC801 

As is shown in Figure 3.2 , a UAX computer may 

interface with more than one memory subsystem. In the 
case of a two-controller, interleaved memory 
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Figure 3.2 Block Diagram of VAX 11/780 Computer. 




con-figuration, the computer would also have two NEXUS 
memory controllers on the SBI . 

The UNIBUS Subsystem (UBUS) is a high speed, 
asynchronous data system that allows communication 
between peripheral hardware and the UAX computer. The 
UAX 1 1/780 is capable o-f supporting -four UBUSes: one is 
standard, but three more are optional (Figure 3.3). The 
UBUS is connected to the SBI through a UBUS Adapter 
(UBA) which per -for ms several important services that 
are transparent to the user. The UBA provides: 

o access to UBUS address space -from the SBI 

o mapping o-f the UBUS addresses to SBI 
addresses for the direct memory access 
(DMA) transfers to the system memory 

o data transfer paths for UNIBUS device 
access to random SBI memory addresses 
and high speed transfer for devices that 
transfer to consecutive, increasing 
addresses 

o UNIBUS interrupt fielding 

o UNIBUS priority arbitration 

The address-mapping function is especially 
important because the UBUS has on 1 y eighteen data lines 
providing an apparent memory-addressing capability of 
only 200 kilo-bytes. Through its address mapping 
abilities, the UBA provides the capability of mapping 
the UN I BUS adar esses into the SBI addresses so that the 
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■full system memory o-f 16 array boards of 256 kilobytes 
each <4 gigabytes total) can be accessed. 

The UBA accepts two forms of input from the UBUS : 
hardware-generated interrupts and direct memory access 
requests. Each device connected to the UBUS may use one 
of five priority levels for requesting bus service. A 
non-processor request (NPR) , which is the highest 
priority request, may be used when the device requests 
an operation that does not require processor 
intervention, such as a direct memory access transfer 
to memory or to some other device. A bus request <BR) 
is thus generated when the device wishes to interrupt 
the UBA for service. Such service might be a 
CPU-directed data transfer or a flag indicating the 
existence of an error condition at the peripheral. 
Since there are only five priority levels and more than 
one device may be connected to a specific request 
level , if more than one device makes the same request, 
the device that is electrically closest to the UBa 
receives the highest priority. 

The NPR request for direct memory access is a very 
important feature of the UBUS subsystem. These DMA 
transfers can be divided into two groups: random access 
of noncontiguous addresses and sequential access of 
sequentially increasing addresses. For random access. 


each UBUS transfer is made through the Direct Data Path 


<DDP, one per UBUS) and is mapped into an SBI transfer. 
This procedure allows only one word of data to be 
transferred during a single SBI cycle. For devices 
capable of requesting sequential access services, use 
is made of the Buffered Data Path <BQP>. Each UNIBUS 
provides fifteen such BDPs which store the data so that 
four UBUS transfers are performed for each SBI 
transf er . 

The DDP must be used by devices not transferring 
to consecutively increasing addresses or by devices 
that mix read and write functions. The max i mumi 
throughput via the DDP is about 425 kilowords per 
second for write operations and about 316 kilowords per 
second for each read operation. These rates will 
decrease as other SBI activity increases CDECSCi]. 

Maximum publ i shed throughput via the BDP is about 
695 kilowords per seconds for both the read and write 
operations, but realistic throughput rates of only 1.5 
megabits per second are actually expected with this 
figure degrading as other SBI activity increases. BDP 
transfers are restricted to block transfers with blocks 
of length greater than one byte. All transfers within 
the block must be to consecutive and increasing 
addresses and al 1 transfers must be of the same 
function, either read or write. 
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The MASSBUS subsystem and the DR78CI high 
perf orma.ice , 32-bit parallel interface will not be 




described in this summary, since an understanding of 
their functional characteristics is not needed to 
determine their relative impacts on the HYPERchannel 
network. The influence of both may be felt indirectly, 
however, since activity on the MASSBUS or DR780 will 
translate to SBI activity which will affect DDP and BDP 
transfer rates as previously described. 

The VAX CPU will also not be described in detail 
but several comments may be made about the CPU and its 
effects on system throughput. The CPU represents the 
most intensive traffic load on the memory subsystem and 
hence on the SBI. Obviously, it the processor is 
engaged in intensive computing, it will request data 
much more often than it will write data, and this 
memory access represents substantial SBI activity. 
Fortunately, the large cache memory of eight kilobytes 
available to the CPU is able to reduce the SBI traffic 
load considerably. In addition to the effects of the 
CPU on SBI activity, the SBI traffic from other sources 
may also affect the CPU efficiency. Published figures, 
[DEC803, indicate that in a system with two memory 
controllers the processor will be slowed by about four 
percent per averaged megabyte per second of I/O 
traffic, while the impact of a single memory controller 
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is to slow the processor by a factor varying from two 
to four. Table 3.2 summarizes the I/O characteristics 
of the DEC ^AX 11/780 processing system. 

The Perkin Elmer 3240 series of computers is also 
a high throughput machine with a 32-bit architecture. 
The HOSC currently uses two PE 3244 machines with 
primary responsibilities as front end processors 
receiving real-time data streams from the KSC firing 
room . 

The 3244 memory subsystem is organized into banks, 
each capable of handling four megabytes of addressable 
memory. Total system memory ranges from 256 kilobytes 
in one bank to a full system complement of four 
4-megabyte banks, for a maximum of 16 megabytes of 
addressable memory. All memory is connected to a common 
memory bus which consists of two unidirectional, 
asynchronous, 32-bit busses. One bus is dedicated to 
memory write functions and the other is dedicated to 
memory read functions (Figure 3.4). 

Input/Output is accomplished using five external 
communication busses: one multiplexer bus for medium 
speed devices and a maximum of four high-speed Direct 
Memory Access (DMA) busses that each support eight high 
speed bidirectional ports. Each DMA port is controlled 
by a selector channel tied to the multiplexer bus that 
controls and terminates transfers through the CPU. Once 
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TABLE 3.2 Sunwiary of DEC VAX 
Character i st i cs 


11/780 I/O 


Processor : 


32-bit word architecture 


Main Memory: 

Virtual address space: 
Cycle Times: 

I/O UNIBUS Adapter 

Maximum aggregate rate: 

Buffered Data Paths <BPD> 
Direct Data Path <DDP): 


4.3 billion bytes . 

800 nanoseconds per 64 
bit read. 

1400 nanoseconds per 64 
bit write. 


1.5 Mbyte/sec throuqh 
BPD 

15 total , 8 byte buffer 
in each. 695 kilowords 
per second read and 
write. Used -for -fast 
data transfers. 

425 k i 1 owords/sec for 
write and 316 kilowords 
per second -for read. 
Used for transfers to 
nonconsecu t i ve memory 
locations. 
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the channel is activated, the processor is released and 
is -free to continue processing on an unrelated task. 
Published I/O transfer rates for the PE 3244 DMA bus 
indicate that transfer rates of up to 10 megabytes per 
second in the burst mode are possible for each DMA bus 
[PEC81]. The I/O characteristics of the PE 3240 series 
is summarized in Table 3.3 [MAUL84]. 
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TABLE 3.3 


Summary of Parkin Elmer 3240 I/O 
Char ac ter i st i cs 


Processor : 

Main Memory: 

Virtual Address Space: 
Cyc 1 e Time: 

DMA Bus Data Transfer Rate 


32 b i t/wor d . 

16 Megabytes. 

500 nanoseconds. 


Burst Mode: 


10 Megabytes per 
second with a maximum 
of 4 DMA busses per 


Chapter 4 

Software Design Description 
This chapter describes the development of the 
software used to model the HYPERchannel network. The 
intent of the simulation is to accurately model the 
characteristics of a HYPERchannel network. Ulh i 1 e , every 
possible function of the network is not characterized, 
the protocols which have the most impact on the network 
were included to the extent poss i bl e . The goal of the 
simulation is to provide a software tool to analyze the 
characteristics of present and future configurations of 
the network at HOSC . 

4.1 Software Functions 

The simulation model as developed should perform 
some primary functions, among these are: 

1) provide a relatively easy method of 
simulating the existing system and 
provide a means for modifying the 
simulation environment so that different 
configurations may be modeled. 

2) provide an output which may be meaning- 
fully converted to performance measures 
described in this Chapter and Chapter 5. 

3) provide a user friendly interface at all 
levels of user interaction. 


The software 

should 

be designed to be as 

por t ab 1 e as 

poss i bl e 

so 

that 

transferral from the 

de ve 1 opmen t 

compu *er 

to 

other 

computer environments 

shou 1 d be 

accomp 1 i 

shed 

as easily as possible. Also, 

any future 
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enhancements o-f the algorithm as designed, should have 
the capability o-f being accomplished as easily as 
poss i bl e . 

Finally, the development o-f this simulation as 
related to the ISQ-OSI model -for distributed computer 
processing (Appendix II), may be thought o-f, as having 
been developed between levels 5 and 6, the Session and 
Presentation levels. 

4.2 Design Constraints 

The primary design constraint placed on this 
simulation e-f-fort was that the simulation be as 
transportable as possible between computers ct 
unspecified size and capabilities. T herefor e , the 
language PASCAL was chosen due to its widespread 
availability and richness o-f data structures. 

4.3 Design Specifications 

This section deals with the imposed constraints 
and assumptions which the model uses to accomplish its 
simulation activity. These assumptions were made to 
keep the model both realistic and manageable. 

4.3.1 Simulation Assumptions 

In order to maintain viability and model validity 
certain assumptions were made. These assumptions are as 


-foil ows : 


1) Every time an adapter requests the 
trunk, the frame sequence sent is a 
message-wi th-data sequence. Therefore, 
message-only sequences are excluded. 

2) Maximum number of trunks is two. 

3) Model will reduce to a single trunk 
mode 1 . 

4) Any single adapter may be attached to 
both trunks (dual trunk model) 

< 1 ,2, . . ,N> 

5) Trunk lengths are less than, or equal to 
1000 feet, Belden 9248 cable data is 
used < propaga V i on time). 

6) Worst case fixed delay, priority delay, 
and end delay will be used, as given by 
[ FRAN84] . 

7) In order for the r.cdel to resemble 

real i ty as closely as possible, measured 
transmission frame times will be used 
< t WATS82) , CFRAN823 ) . 

8) Intra-adapter communication is not 
al 1 owed . 

9) The wait flip-flop option is not 
i mp 1 emen ted . 

4.3.2 Parameter Definition 

As previously stated worst ca.se values of fixed 
ae 1 ay , priority delay, and end delay are used in the 
simulation. The expression used to evaluate the fixed 
delay on a given trunk is given by: 


Fixed delay = 4 nsec * (trunk length) * 2.08 usee (1) 


where trunk length is given in feet. This value 
approximates, but is greater than, twice the end-to-end 
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propagation time -for the trunk, plus the time required 
by the adapter to -formulate and to begin transmitting a 
response. This value is the same tor each adapter on a 
gi ven trunk . 

The highest pr i or i ty adapter is assigned a 
pr i or i ty delay o-f 0.48 usee. The priority delay -for the 
remaining adapters on a given trunk is given by: 

Priority delay (K) = Priority delay <K-1) 

+ 4 nsec * d + 1.6 usee, (2) 

K = 2 , 3 , . . . . L 

where K is the index o-f the adapter with priority K and 
d is the distance in feet between the adapter with 
priority K and the adapter with priority (K-l), L 
refers to the lowest priority adapter. The constant 1.6 
usees is added to alleviate problems with line 
reflections. 

The end delay of the adapter with priority K is 
given by : 

End delay <K> = Priority delay <L> 

+ nsec * d + 1.6 usee, (3) 

K = 1,2, L 

where L is the lowest priority adapter, and d is the 
distance, in feet, from the adapter with priority K to 
the adapter farthest from it [FRAN84], 
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These are the major parameters which need to be 
calculated -for a given configuration of the 
HYPERchannel network. They are calculated for * given 
configuration when the simulation program is executed. 
4.4 Algorithm Description 

In this section an eve rail view of the activity of 
the simulation is detailed. Detailed descriptions of 
the individual modules used by the program are found in 
Appendix III. 

4.4.1 Overall Simulation Activity 

The simulation as developed is a discrete event 
simulation. The event that drives the model is an 
adapter's next scneduled transmit time. An adapter 
trying to transmit will attempt to obtain a trunk in 

three given time frames. An adapter may try to transmit 
while the trunk is busy, during the priority delay or 

scheduling period, or finally, in the contention 

period. If an adapter attempts to transmit while the 
trunk is busy its next transmit time is adjusted to its 
scheduling period time (priority delay). If an adapter 
attempts *o transmit during the scheduling period one 
of two possibilities exist: 1) it attempts to transmit 

after fixed delay but before its prio-’ty delay event 
and 2) it attempts to transmit after its priority delay 
event but before the and delay event. In the first 
case, the adapter is allowed 4- o transmit at its 


priority delay event and in the second case, the 

adapter is -forced to wait until ics end delay event is 
signalled. This is in accordance with NSC's trunk 
access protocol. An adapter attempting to transmit 
during the contention period is allowed to do so 

provided that the trunk is sensed idle. Once the 
adapter has gained acces 1 to a trunk through the trunk 
access protocol as modeled, it will proceed to send its 
message sequence. 

In Figure 4.1, a complete message-wi th-data 
sequence is shown. Appropriate timing and program -flags 
(Ml through M6) are indicated, the algorithm shown in 

Figure 4.2, in flow diagram form, illustrates the 

overall activities of the simulation program. Using 
these two figures a basic description of the program 
flow may be performed. The first three blocks in Figure 
4.2 perform initialization of program variables, 
definition of the network configuration, and prints a 
description of the network to the auxiliary file Auxout 
maintained by the program. Once trunk access has been 
granted (previously described) an adapter will attempt 
to send transmission frames and data frames. Program 
flags are used to indicate where in the 
message-w i th-dat a sequence the present transmitting 
adapter is located. The various update blocks (Casel 
through Case?) update timing, bit counts, and flags. 
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Case2 incorporates the adapter reservation scheme 
(Figure 2.9). If a receiving adapter can be reserved 
tor the transmitting adapter the message sequence 
transmission will continue, otherwise, the adapter will 
return to case2 each pass through the loop, until it 
reserves its receiver or aborts its transmission. The 
message proper frame is updated in cese4. A message 
length of 64 bytes is assumed for convenience. Case5 
updates the transmission segment in which a data block 
is sent. In case6, determination of whether or not 
another data sequence needs to be sent (based on the 
attached device's buffer size) is made. If another data 
block is required, then the period of time t'- t" will 
be repeated, this will continue as required. In case?, 
updates to message delay (the time difference between 
initial transmission time and the final transmission 
time), trunk sequence transmission tally, and adapter 
next transmission time are performed. The transmitting 
and receiving adapter's are released for other 

transmissions in case7 also. The simulation will 
continue until the user defined maximum time or the 
maximum number of message sequences is exceeded. The 
simulation will then print output statistics to an 
interactive terminal and an output file. 
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4.4.2 Model Set-lJp 

Figure 4>3 illustrates the basic set-up oi the 
network con-figuration which the simulation program 
operates on. All con-figurations to be modeled should be 
set up according to this diagram. In the case o-f a 
single trunk configuration, adapters 1 through N are 
used . 

The simulation (Siml) uses this model 
configuration to properly identify and characterize the 
network adapter's, their attached devices, and data 
sources . 

4 . 5 System Files 

There are three files associated with the 
simulation: program, Df i 1 e , and Auxout files. The 

program file (Siml) may be maintained as either source 
or object code since normal operation of the program 
requ i res no changes to the program file. The f i i es 
Df i 1 e and Auxout are maintained as standard ASCII text 
files. Df i 1 e contains a description of the network, and 
is used by the program file for parameter values. 
Auxout contains a text description of the network and 
is used to store output statistics from a particular 
program execution. 

At the beginning of a program execution, an 
interactive query allows the user to use the network 
configuration defined in the Df i 1 e or define a new 


6 ? 



Figure 4.3 Model Set-Up for Simiilati 











v. • -a. \ v: v 




con-figuration, which is then placed in this -file. The 
auxiliary -file Auxout, is a print -formatted -file and 
may be directed to a printer -for a hard copy o-f a 
program execution's statistics. Additionally, Auxout is 
totally maintained by the program -file and thus is 
transparent to the user until a print out o-f a 
simulation run is desired. 

4.6 Reported Statistics 

The network statistics, as compiled by the model, 
are such that they allow the computation o-f measures 
which indicate network performance . These measures are 
de-fined as -follows: 

o D: The delay that occurs -from the time 
an adapter becomes ready to transmit 
a message sequence until it actually 
completes its transmission. 

o S: The throughput o-f the local network; 
reported as the total rate o-f data 
transmitted over the network. 

o U: The utilization o-f the network; this 
is given as normal ized throughput. 

o G: Offered load; the total rate of data 
presented to the network. 

where possible the statistics necessary to calculate 
these measures will be reported for the entire network, 
the individual trunks, and the individual adapters. 


4 . 7 Val i dat i on Criteria 

While every attempt has been made to make this 
simulation as close to the real system as possible, 
software implementation of an electronic system has its 
limitations. This simulation effort has been aimed 
primarily at modeling the various protocols implemented 
by a HYPERchannel network. It has been shown that these 
protocols are the -factors having the most impact on 
system performance CFRAN84], CWATS80 ] , CDGNN79], and so 
on. There -fore, the simulation was designed to model 
these parameters as closely as possible. The validity 
o-f this model rests on a clear understanding o-f the 
operation o-f HYPERchannel networks and the relationship 
o-f this operation on system performance. 

Finally, it was not feasible or practical tc 
establish a validation test bed at HOSC . This due 
largely to the requirements placed on the -facility and 
its stated mission. Thus, the mode 1 validation was done 
empirically, based on knowledge o-f the HYPERchannel 
system and the components attached at HOSC. 
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Chapter 5 

Model Analysis and Conclusions 
In this chapter some of the theoretical consider- 
ations involving HYPERchannel network performance 

measures will be developed. The results of exercising 
the model in various configurations (based on the HOSC 
system and components) will be presented. Finally, the 
conclusion section, will attempt to describe the 
results and their relation to operating conditions at 
HOSC . 

5.1 Theoretical Performance Bounds 

In Chapter 4, several statistics were discussed as 
being important -ndicators of network performance. 
These were identified as S, U, and D. S defined as 
throughput, is the rate of data flow on the network. U 
or utilization, is normalized throughput, this being 
the fraction of network capacity being utilized, and 
finally, D or delay, is the delay between the time an 
adapter requests the trunk and the t • me at which it 
completes a transmission. In order for the experimental 
values to have meaning, some theoretical determination 


of 

these 

st a t 

1 St 1 cs 

1 s 

needed so 

that comparisons may 

be 

made . 

I n 

or der 

to 

determine 

theoretically these 


values, the network factors which most affect HSLN 
performance must be known. The factors which affect 


t 

i 

this pertornjnce , independent of the attached equipment 
ar e : 

o Bandwidth 
o Propagation delay 
o Number of bi ts per -frame 
o Local network protocol 
o Offered 1 oad 

o Number of stations CSTALL84] 

• 

The first three of these factors determine a 
parameter a, from which the network utilization U, and 

* 

throughput S mi/ be determined. 

Since a local area network is distinguished from 
long haul networks and multiprocessor systems by the 
bandwidth \ B ) and distances ( d > involved. The product 
of tnese two terms • B ♦ d.< can be used to characterize 
the network. The transmission length of the medium may 

j 

be determ-ned b/ dividing this quantity by the 
propagation velocity of the medium. This quantity 

mi' be calculated as follows: 

Transmission Length = B ♦ d 

u 

Network System s Corporation suggests a value of 
40 percent of the speed of 1 i gh t be used tor 

propagation velocity wh en attempting to establish 

network performance. Using the value of *0 Megabits per 
second for B. assuming d to be 1000 feet, and using a 

r 

. 1 
. a 
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value ot 1.2 x 108 me ter s/sec -for propagation velocity, 
the theoretical transmission length o-f a 1000 -foot 
HYPERchannel network is 127 bits. 

The ratio o-f transmission bit length, to the 
length o-f a typical -frame (L) is the dimensionless 
quantity a . Thus , 



typical 

or 



jl = 

Bd 



L'L 


Since 

d/ V i s 

the 

the med i urn 

i t may 

be 

Fixed Delay. 

Rec al 1 

i ng 


may be calculated as 

Fixed Delay = 4 nsec * (trunk length) + 2.08 usee, 

the parameter a may be calculated as 


a = B * (Fixed Delay) 

L 

Thus -for a HYPERchannel trunk o-f length 1000 -feet, 
a is determined to be 0.0109. Typical values o-f a -for a 
HSLN range -from 0.01 to ove~ 1. rtn intuitive discussion 
o-f the meaning ot the parameter a is -found in William 
Stalling's Local Networks . This parameter is used to 
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prov i de 
ne twork 
appears 
part of 


an upper bound on the utilization of the 
Stallings also points out that this hypothesis 
to be supported by experimental evidence; a 
this discussion -follows: 


....Consider a perfectly efficient access 
mechanism that allows only one transmission 
at a time. As soon as one transmission is 
over, another node begins transmitting. 
Furthermore, the transmission is pure 
data — no overhead bits.... what is the 
maximum possible utilization of the network’ 
It can be expressed as the ratio of total 
throughput of the system to the rapacity or 
bandw i dth : 


U = thr ouohpij t 
B 

= L/ ( Pr cp aoa t i on + transmission time.) 

B 

= L/<D/U ♦ L/B) 

B 

= 1 
1 + a 

So , utilization varies inversely with a 

[ STALL84] . 

Table 5.1 shows an example using _a to predict the 
theoretical bounds on a network similar to the system 
at HOSC . Unfortunately, this method does not account 
for the access protocol of the network. Furthermore, it 
assumes that the maximum propagation time is incurred 
on each transmission and that only one transmission may 
occur at a time. Despite these shortcomings, upper 
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Table 5.1 Theoretical Bounds on a HYPERchannel 
Trunk o-t Length 1000 Feet. 


Fixed Delay = 6.08 usee 
Bit Length = 127.0325 bits 
a = 0.0109 

U = 1 = 0.9892 

1 + a 

S = U * 6 = 49.46 Mbits/ sec 

For an arbitrary period c+ time, t, the total bits 
tr anster red are : 

Total Bits = S * t 

■for t = 40 seconds 

Total Bits = 1978 Megabits 
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bounds on throughput and utilization may be calculated 
using these techniques. 

Another derivation of utilization which takes into 
consideration the effects of the protocol on the 
network performance, based on the work of Robert 
Metcalfe and David Boggs [METC76] is considered. Their 
work is based on the Ethernet system which is a local 
area network operating under a CSMA/CD medium access 
protocol with characteristics similar to HYPERchanne 1 . 

Assume that there are N active nodes on the 
'ivtworl: , each having identical data generating 
^ har ic ter i s t i cs . Furthermore, after a station has 
transmitted its packet, another station becomes ready 
to transmit its packet, so that N also represents the 
total offered load on trie network. Stallings in his 
amplification of CMETC76] notes that time on the 
network may be divided into two components: 
transmission interval (time required to transmit a 
complete packet over the medium) and a contention 
interval (sequence of slots with a collision or no 
transmission). Throughput then, becomes the ratio of 
time transmitting to the total time. 

Recall that a may be written as 

a = p r opaoat ion t i me 
transm i ss i on t i me 
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where 

the 

propagation time is 

the worst 

case value of 

1 1 me 

to 

tr ansm i t a frame 

over the 

medium, and 


transmission time is the time required to get a 
complete frame onto the medium. If transmission time is 
normalized to one, then a becomes propagation time. The 
minimum length of the transmission slot must be chosen 
to allow for the detection of a collision and is equal 
to twice the end-to-end propagation time < l/2a) . 

Following Stalling's approach for the development 
of the equations describing throughput and utilization, 
the average length of the contention interval is 
cetermined by first computing A, the probability that 
exactly one station attempts a transmission in a slot 
and acquires access to ths medium. This is the binomial 
probability that any one station attempts to transmit 
and the others do not, 



= Np(l - p 'N “ 1 

which is the probability that the desired occurrence 
(acquisition of the trunk) will occur i r, N independent 
trials. Since maximum throughput and utilization are 
tne quantities of interest, maximizing A will require 
that p = 1 / N so that, 


7? 


1 /N > N 


i 


A 


The estimated mean length of contention interval, 


slots 

i s « 







EC w] = 

2 

i=i 

i * 

Prti slots in row with a collision 
or no transmission followed by a 
slot with no transmission] 

— 

om 

2 

i ( 1 

- A) i rt 


i = 1 



converges 

to, 



Etw] = 

1 - A 

[ STALL84] . 




A 





Th e 

max i mum 

v a 1 u e 

of util 

i zat 

i on may now be 

de termi ned , 

which i 

s the 

1 ength 

of 

a tr ansm i ss i on 


interval as a proportion o* a eye i ? consisting of a 
transmission and a contention interval 


U 


tr ansm i s s i on t i me 
total time 

t r an sm i ss i on t i me 

transmission time + contention time 

1/2 a 

1 .'2a + <1 - A)/A 

1 


1 + 


2a 1 


A 


For the 1000 ■foot HYPERchanne 1 network previously 
described, assuming N = 4, U = 0.971 and S is 48.55 
Megabits per second which corresponas nicely with the 
results obtained using only a (Table 5.1). 

The calculation ot the parameter D or message 
delay is not so obvious. It appears empirically, that D 
increases without bound as the network approaches 
saturation. As the number ot nodes increases, so do the 
number ot access requests, the number ot collisions, 
the number ot r e tr ansm i ss i ons and also the time delay a 
node experiences betore access is obtained, so 0, does 
appear to increase without bound. 

5.2 Presentation ot Simulation Results 

The previous section presented analytical 
techniques useful tor predicting the peak, or upper 
limits ot a HYPERchanne 1 network's pertormance . While 
this is usetul tor predicting top end pertormance, it 
does not provide any usetul intormation about a 
particular cont i gur at i on ot the network. 

The purpose ot this simulation ettor^ is to 
provide the engineers and scientists at HGSC with a 
sottware tool which will provide intormation on network 
p er t orman c <=■ in a variety ot cont i gur at i ons . This 
section presents results trom this model tor the 
network descriptions shown in Figures 5.1 and 5.4. 
Detailed descriptions ot these cont i gur at i ons , along 
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with simulation results are gi yen in section 5.2.1 and 
the results tor a dual trunk configuration are given in 
section 5.2.2. 

5.2.1 Single Trunk HOSC Results 

The single trunk configuration, as shown in Figure 
5.1, and defined in terms of the model in Appendix IU , 
was considered. Table 5.3 contains a listing of the 
relative p r obab i 1 i t i e s that a given transmitter will 
attempt to transmit to a given receiver. This is used 
by the simulation to es t ab 1 i sh the virtual connection 
be tWs* a n devices for communication. In order to gauge 
the performance of this configuration over a wide range 
of input loading, the topology of the network as 
defined was kept constant. The offered load to the 
network was varied bv increasing the data source 
generation rates to the devices shown. 

Table 5.2 illustrates ‘.he me t h od for c omp u ting 
system performance measures from simulation statistics. 
Tables 5.4 and 5.5, contain data points calculated from 
simulation runs, with each data point representing a 
simulation run. These data points were plotted as shown 


Table 


5.2 


Calculation o-f Parameters using 
Simulation Statistics. 


S (throughput) = Total Bits Transmitted 

Simulation Time 


U (utilization) 


S 

Bandw i dth 


S (bits ) 

50 Mbits per second 


D (delay) = Aug. Message Delay Device 1 

+ Avg. Message Delay Device 2 

+ . Avq. Message Delay Device n 

n 


The above expression -for delay is used in the case 
where transmitting devices have -finite Average Message 
Delays. For the case where a transmitting Device 
attempts to transmit messages but has an Average 
Message Delay equal to zero (Average Message Delay = 0, 
and Abort count >0) it is assumed, that Message Delay, 
or Delay, -for the Network exceeded simulation time. 

0-f-fered Load is compiled by the simulation and 
output as one o-f its statistics. 


Table 5.3 Relative Probabilities for Transmitter/ 
Receiver Pairs tor Figure 5.1. 








\u 


Transmi t ter/Rece i ver 
111-311 
1 1 1-321 
21 1-431 
221-421 
31 1 -21 1 
311-221 
321-21 1 
321-221 
331-421 


Pr obab i 1 i t v 
0 . 7 
0.3 
1 . 0 
1 .0 
0.01 
0.01 
0.01 
0.01 
1 .0 
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. 0008092 

.0001295 

.0234998 

.0009933 

.0024680 

.0003949 

.0470083 

.0021383 

.0040020 

. 000640 3 

.0705255 

.0019500 

.0067190 

.0010751 

.1121140 

. 001^833 

.0142275 

. 0022764 

.2242640 

.0016166 

. 0 29 Q 95 e» 

.0046553 

.4486710 

.0015533 

.0431299 

.0069008 

. 6733410 

.0016950 

.0586719 

.0093875 

.8984520 

.0016283 

.0730755 

.01 16921 

1 . 1 224500 

.0015116 

. 1421105 

.0227377 

2.2420000 

.0018583 

.21 13972 

.0339036 

4.4840000 

.0042466 

.320281 3 

.0512450 

6.7297000 

.3875766 

.5137168 

. 0 821946 

8 . 9692300 

. 0064750 

.5548880 

.0387821 

1 1 .2103000 

.0042916 

. 9260 1 50 

. 1497624 

22.4200000 

/ 40 

1 .5409865 

.2465578 

44.8401000 

>40 

2.3634713 

. 3781 550 

67 . 2603000 

>40 

2.3250275 

.3720044 

89 . 6800000 

.4622500 

3 . 4732500 

.5557200 

224 . 2000000 

>40 

3.6444500 

.5831 1 20 

448.4000000 

>40 

4.5387500 

.7261400 

672 . 60 000 00 

>40 

4.6086250 

.7373800 

896 .8000000 

>40 

4 . 6531500 

. 7445040 

1 1 21 .0000000 

>40 

4 . 7345000 

.7575000 

2242.0000000 

>40 

4 . 35 1 6500 

.6962640 

4340 .0000000 

>40 

4.3016750 

. 7682680 

6726.0000000 

>40 

4.3004000 

.7680640 

8968 . 0000000 

>40 

4 . 7973500 

.7676560 

11210. 0000000 

>40 











T »bl e 

5.5 Data Points -for Figure 

5.3. 

Control 

Bi ts 

Data Bi ts 

6 Bits 

Mbits 


Mbits 

Mb i t s 


.1005832 

.177536 

.1879984 

. 3076200 

.520456 

. 3760 664 

.4885992 

.854160 

.5642040 

.6720912 

1 . 163416 

.7210600 

.7758192 

1 .374581 

.8969120 

1 . 6394960 

2.914616 

1 .7941 1 20 

3.3552960 

5.960952 

3.5893680 

5.0973920 

8.719360 

5.3867280 

6.8325440 

1 1 .977040 

7 . 1376160 

8.4246400 

1 4 . 989760 

8.9796000 

16.4381200 

28.992240 

17.9360000 

27.11 o8800 

40 . 690 1 60 

35.8720000 

43.6347200 

58. °1 1760 

53.8376000 

62.5479200 

101 .864000 

71 .7538400 

74.7621600 

102.307200 

39.6824000 

134.9088000 

164.616000 

179.3600000 

204.0576000 

289.070400 

358.7208000 

347.8608000 

408.488000 

538.0824000 

353.9296000 

390.079200 

71 7.4400000 

539.0768000 

572.364800 

1 793.6000000 

685.7088000 

480 .517600 

3537.2000000 

582 . 9048000 

869.376000 

5380 .8000000 

5 6‘. .0 320000 

910.728000 

7174.4000000 

564.3920000 

924 .616000 

89 63 . 00 0 0 000 

543.6464000 

971 .392000 

1 7936.0000000 

624.7024000 

767.824800 

34720 .0000000 

527.3368000 

1008.696000 

53803.0000000 

528. 1 1 36000 

1008.008000 

71744.0000000 

528.7163000 

1006.600000 

39680 .0000000 
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Figure 5.2 Plot of Transmitted Control and Data Bits 

versus Offered Load for Single Trunk Simulation. 
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The system con-figuration and data -flow rates 
indicated in figure 5.1 are a typical loading of the 
main trunk of the HOSC system. The total offered 
load (G) for the system as depicted in figure 5.1 is 
computed as follows (G the offered load is the total 
number of data bits offered to the channel): 

DEVICE DATA ARRIVAL RATE 


1 i 1 

15 

kbytes/sec 

s 

120 kbps 

21 1 

4 

kbytes/sec 

= 

32 kbps 

221 

6.4 

kbytes/sec 

= 

51 .2 kbps 

31 1 

1 

kbytes/sec 

= 

8 kbps 

321 

1 

kbytes/sec 

3 

8 kbps 

331 

.625 

kbytes/sec 

= 

5 kbps 

41 1 


0 



421 


0 



431 


0 




TOTAL OFFERED LOAD = 224.2 kbps. 

In a 40 second period a total of 8.976 Mbits or 
6.953 (Log bits) would be offered for transmission 
across the HYPERchanne 1 * network. Referring to 
figure 5.2 the utilization of the HYPERchannel trunk 
for this offered load is approx i mate 1 y . The 
throughput rate is thus (.02) * (50 Mbits per 

second) = 1 Mbps. Obviously the system is nowhere 
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near its upper limit in data throughput rate, trunk 
utilization and hence not in offered load. 

The approximate number of total bits 
transmitted to send a 2 kbyte block of data may be 
estimated from figure 2.8 using Table 2.2 as a 
reference. From figure 2.8 it is apparent that 7 
transmission frame format fields, 9 response frame 
fields, and 2 response frames with data format 
fields are transmitted to accomplish the 
transmission of 2 kbytes of data. This amounts to 
an absolute minimum transmission of 19600 bits total 
for 16000 bits of data or absolute minimum overhead 
of 22.57.. For longer data blocks the overhead is a 
smaller percentage and may be calculated by the 
relationship (assuming no collisions): 

ABSOLUTE MINIMUM TOTAL BITS SENT 
PER 2 KBYTES OF DATA = 19600 ♦ (N-n 18600 

where N = the number of 2 kbytes of 

data . 

The reduction in transmission overhead for 
multiple transmission of data segements 
of 2 kbytes of data is not significant in number of 
bits transmitted but the timing and number of times 
the channel is free for contention is reduced by a 
significant amount. It will be observed from the 
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simulation runs that an average overhead o f 50/C tor 
low ottered load and 100X tor high ottered load is 
the case. This overhead increase is due to the 

non-intege- multiples ot 2 kbytes ot data to be sent 
and to collisions. 

Figure 5.3 depicts the average delay and number 
ot collisions versus ottered load. The average 
delay is an aggregate delay number and a 1 aroe delay 
is indicative that at least one device is 

experiencing a large delay. Thus it may irlmate 
that only one device is unable to transmit but all 
the remaining de^'ces may be transmitting 
sa t i s f ac tor i I y . However it is an indicator that 

things are begining to sour on the overall network 
performance . 

Likewise the number of collisions is an 

aggregate sum and indicates the relative number of 
retry transmission attempts the system is 
experiencing. Since the HYPERchannel is not a pure 
contention system (such as ETHERNET) the increase of 
collisions does not necessarily indicate 
accompanying data loss or absolute inability of an 
adapter to communicate. Again it is an indicator 
that things are not so well on the overall network. 




From the results of figure 5.3 it is apparent 
that as the offered load increases past about 7.5 
<31.62 Mbits for 40 seconds or 790 kbits per second) 
the system is beginning to experience traffic 
congestion. The system's trunk utilization, figure 
5.2, is seen to start a rise at this point (7.5) of 
nfftred load and it may be observed that at an 
offered load of about 9.5 <3162 Mbits for 40 seconds 
or 79 Mbits per second) the trunk utilization is 
entering saturation. At this point it is safe to 
say that some devices are just not able to transn.it 
all their data. Somewhere in between these two 
offered loads is a point that would do well to be 
identified as the maximum useful offered load 
condition. Using the rule of thumb for normal 
maximum operating offered load for pure contention 
systems (ETHERNET is an example of a pure 
contention system) the maximum operating offered 
load would be set to approx imate 1 y l/2e or 13.3571 of 
the channel bandwidth. For slotted contention 
systems this rule of thumb figure is approx i mate-1 y 
1/e or 36.771. The HYPERchannel is a hybrid 
priority/contention system with prioritized time 
slotting and it is reasonable to expect to load the 
system to the 36 . 771 trunk utilization. Inspecting 
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the graph of trunk utilization versus offered load, 
figure 5.2, it Is observed that the offered load for 
a utilization figure of 3 6.7V. is approximately 8.5 
< 1 og bits) or a 7.9 Mbps aggregrate rate (316 Mbits 
in a 40 second) . 

Inspection of the graphs for the transmitted 
control bits and the transmitted data bits versus 
offered load, figure 5.3, also illustrate that at 
8.5 offered load the control bits and data bit 
curves start to enter saturation. Thus it is 
reasonable to state that the maximum operating 
offered load (in pure aggregrate rate data bits) 
should be 8.5. This is an aggregrate rate of 

offered data of 7.9 Mbps or 1 5 . 87. of the channel 
bandwidth of 50 Mbits. Remember that an absolute 
minimum of 22.57. overhead is needed at low collision 
rates and thus 7.9 Mbps of offered data plus 27.57. 
overhead is approx i mate 1 y 9.6775 Mbps or 19.357. of 
the channel bandwidth. (This assumes all data 
blocks are integral 2 Kbytes in size). 

A further comment of the figure 5.3c and 5.3 d 
is in order. The offered data to the channel , G, 
(see Table 5.5) is only the actual data to be 
transmitted. The actual number of data and control 


bits required (as evidenced from the 


s i mu 1 at i on 


runs), which when added together equal the channel 
throughput S, will not equal G but be greater than 
6 . 

It should be observed that -for low offered load 
the actual transmitted bits on the channel amounts 
to 2.54 times the offered load and at high offered 
load this figure decreases to about 2 times the 
offered load until saturation takes place. This 
apparent increase in efficiency is misleading since 
the prioritized time slotting mode of operation 
replaces the contention portion of the channel 
algorithm and stagnation of the throughput <U*B> 
takes p 1 ace . 

Thus the 7.9 Mbps offered aggregate load 


corresponds to 

abou t 

16 Mbps 

to 

18 

Mbps 

ac tual 

channel offered 

total 

1 oad or 

367. 

of 

the 

channel 


bandw i dth . 

FROM THIS DISCUSSION AND THE SIMULATION 
RESULTS COUPLED WITH THE ANALYTICAL RESULTS 

IT IS RECOMMENDED THAT THE TOTAL AGGREGATE 
OFFERED DATA TO THE HYPERchannel SHOULD BE 
HELD TO 8 Mbps OR LESS. IN FACT DUE TO THE 
UNCERTAINTY OF ESTIMATING AGGREGATE DATA RATES 
A MAXIMUM OF 4 Mbps WOULD SEEM PRUDENT. 


mrv \ , 




5.2.2 Dual Trunk HOSC Results 

The dual trunk con-figuration as shown in 
Figure 5.4 and detailed in Appendix V , was 
considered. Once again, the relative probabilities 
•for transm i t ter/ 

receiver pairs in this con-figuration are contained 
in Table 5.6. In order to compare the e-f-fect o-f the 
dual trunk con-figuration with the previous results, 
the con-figuration o-f trunk 2 in Figure 5.4 was 
defined as the single trunk c on -f i gu r a t i on 

previously considered. The topology o-f this 
con-figuration was held constant and the o-f-fered 
load varied, the resulting data points are 
contained in Tables 5.7, 5.8, and 5.9. These data 

points were plotted as shown in Figures 5.5, 5.6, 

and 5.7. 

In a secenario that has been judged to be a 
normal environment for the HOSC dual trunk system, 
the transmissions from trunk 1 to trunk 2 have 
aggregate data rate of 10 kbytes/sec . The device 
on trunk 1 always transmitts across the trunks to 
trunk 2. The cross traffic from trunk 2 to trunk 1 


has a 1 ower 

data rate and 

a 1 ower pr obab i 1 i 

ty 

of 

request for 

transm i ss i on . 

Thus the maj or i 

t y 

of 
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Table 5.6 Relative Probabilities -for Transmitter/ 
Receiver Pairs -for Figure 5.4. 


Transmi tter/Rece i ver 

Pr obab i 1 i ty 

1 1 1-521 

1 .0 

211-411 

0.7 

21 1-421 

0 . 3 

31 1-531 

1 .0 

321-521 

1 .0 

321-1 1 1 

0.3 

41 1-31 1 

0.01 

41 1-321 

0.01 

421-31 1 

0.01 

421-321 

0.01 

431-521 

1 .0 
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able 5.7 Data Points -for Figure 5.5 (Trunk 1) 


S 

Mbytes/sec 


.00017973 
.00065895 
.001 16560 
.00161704 
.00239248 
.00711533 
.011 89340 
. 0 1 665555 
.02376770 
.07053307 
. 1 1621025 
. 1 6076790 
.22569486 
. 60678250 
. Q 1 607500 
1 .17207750 
1 .50327750 
.52247200 
.93269750 
.15442500 
. 34350000 
.49356500 
.52475250 
3.54453500 


u 

8 

Mby t e s 

Average 1 
secs 

.000028758 

.0155758 

.0006650 

.000105433 

.0467330 

.0013928 

.000186500 

.0760532 

.0013800 

.000258726 

.1090710 

.0015842 

.000382797 

. 1521 190 

.001 4942 

.001 138454 

.4564050 

.0013442 

.001902940 

.7610820 

.0013142 

.002664880 

1 .0658600 

.0013000 

.003802830 

1 .5233900 

.001 3000 

.011285292 

4.5644800 

.0013228 

.018593600 

7 . 60 50000 

.0064371 

.025722800 

1 0 . 6496000 

.0014928 

.0361 11111 

15.21 16000 

.0067786 

.097085200 

45 . 6300000 

.0288557 

. 146572000 

76.0500000 

.0977300 

. 187532400 

106.4700000 

>40 

. 240524400 

152.1 000000 

.7125557 

.403590000 

456.3000000 

>40 

. 469231 600 

760.5000000 

>40 

.504700000 

1064.7000000 

>40 

.534960000 

1 377.0000000 

>40 

.558970000 

4563.0000000 

>40 

. 5o3960400 

7605.0000000 

>40 

.567125600 

10647.0000000 

> 40 


100 


to ro 


3 v V 


mm ii in 


Table 5.8 Data Points -for Figure 5.5 (Trunk 2). 


Mbytes/ sec 


G 

Mbyte 


Average D 
sec 


.00017973 
.00142330 
.00204550 
.00321635 
.00478900 
.01557770 
.02641426 
.03715009 
.05333650 
. 1 6056906 
.16651 150 
.32703950 
.34178971 
.86553250 
2.49451500 
1 . 38427372 
.05963550 
. 24608750 
1 .88915240 
1 .92437440 
1 .93925400 
2.31413420 
2. 38785975 
2.40758250 


.000028758 
.000227728 
.000327280 
. 000514616 
.000766240 
.002492400 
.001902940 
.005944016 
.008533800 
.025691050 
.026641800 
.052326322 
.054686000 
. 1 38485200 
. 399122400 
. 221 483800 
.329541600 
.519374000 
. 302260000 
.307899000 
.310280000 
.370269000 
. 382057500 
. 385200000 


.0155758 
. 0467330 
.0760532 
. 1090710 
. 1521 190 
.4564050 
.7610820 
1 . 0658600 
1 .5233900 
4 . 5644800 
7.6050000 
1 0 . 6496000 
15.2116000 
45 . 6300000 
7o . 0500000 
106.4700000 
152. 1000000 
456 . 3000000 
760 . 5000000 

1064.7000000 

1377. 0000000 

4563 . 0000000 

7605.0000000 
10647.0000000 


. 0 00 6650 
.00 1 8928 
.0018800 
.0015842 
.0014942 
.0013442 
.0013142 
.0013000 
.0013000 
.0013228 
.0064371 

.0014928 
. 0 0 67786 
.0288557 
.0977300 

V-.O 

.7125557 

>40 

>40 

>40 

>40 

>40 

40 

>n0 
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Table 5.9 Data Point* tor Figures 5.6 and 5.7 


Trunk 
Con trol 
Mbits 

1 

Data 
Mb i ts 

Trun 
Con trol 
Mb i t s 

k 2 

Da t a 
Mbits 

G 

Mb i ts 

.327870 

.0261 1 2 

.327870 

.0261 12 

.12460 

.120219 

.095744 

.229786 

. 236680 

. 37386 

.207651 

. 1 65376 

.339076 

.315528 

.60842 

.295033 

.235008 

.528275 

. 526096 

.37256 

. *42623! 

.339^56 

.761190 

.771480 

1 .21695 

1 .267768 

1 .009664 

2.416856 

2 . 5691 76 

3.651 24 

2.120224 

1 .688576 

4.083456 

4.375576 

6 . 08865 

2.972688 

2.367488 

5.728200 

6.172760 

8.52688 

4.240456 

3.377152 

8.220800 

8.873630 

12.18712 

12.568320 

10.009600 

24.684128 

26.717520 

36.51584 

20 .699520 

16.485360 

44.027040 

9.256640 

60 .84000 

28.644880 

22.313200 

59.468240 

45.209520 

85. 19680 

40 .20 7760 

32.022000 

93.209o00 

10.174320 

121 .69280 

108.088000 

36.082400 

193.222400 

83.748000 

3c5 .0*1000 

163.210400 

129.933600 

41 l .237600 

38.700720 

608 . 40000 

208.792000 

1 66 . 272800 

440 . 861600 

2.105992 

851 . 7o000 

274.172000 

206 . 876800 

631 .389600 

27.193760 

1216.80000 

449 . 335200 

357.856000 

396 . 320000 

142.428000 

3650 . 40000 

522.41 1200 

416.052000 

607.649600 

.032768 

6084 .00000 

561 .916800 

447.499200 

615. 689600 

. 1 1 0208 

8517. 60000 

595.596800 

474.324800 

620.444800 

. 1 t 6488 

1 1C 16.00000 

' 60 . 745600 

457.195200 

717. 393600 

23.145360 

36504 . 00000 

6. 3.976000 

453.948000 

733.200800 

30 .914320 

60840 .00000 

679 . 876000 

454.375200 

732.420800 

38 . 005600 

85176. 00000 
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Figure 5.6 Plot of Transmitted Control and Daca Bits 

versus Offered Load for Duel Trunk (Trunk 1) 

S imulation . 
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the cross trunk transmissions occur from trunk 1 to 


trunk 2. This is envisioned as the worst case 
condition for cross trunk traffic since the 
destination trunk is the busiest trunk. 

Looking at the curves from figures 5.5, 5.6 
and 5.7 it may be observed that for trunk 1 the 
operational parameters under increasing offered 
load are very similar to that for the single trunk 
secenario, the exception being the lowered trunk 
utilization before saturation is encountered. 
Again the maximum offerea load operationg point is 
seen to occur for about 3.5 offered load and hence 
as before the trunk 1 aggregate offered load should 
be held to 8 Mbps or less. 

The situation is not as good for trunk 2. The 
cross trunk traffic hampers the normal traffic flow 
for trunk 2 and it is apparent from the simulation 
curves that the maximum aggregate offered data load 


should be held 

to 

1 ess 

than 8 or 

2.5 

Mbps . Th i s 

1 s 

cons i der ab 1 

y 1 

ess 

than 

that for 

the single trunk 

simulation 

and 

cl 

early 

demonstrates 

the effect 

of 


heavy cross trunk communication requ i rements. 

From figure 3.4 the aggregate offered data 
load of the two trunks may be calculated. This 
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was judged to represent a typical operating load 
for the dual trunk HOSC system. 


DEVICE 

DATA 

1 ARRIVAL RATE 


1 1 1 

10 

kbytes/sec 

3 

80 

kbps 

TRUNK 1 

TOTAL OFFERED LOAD = 


80 

kbps 

21 1 

15 

kbytes/sec 

3 

120 

i kbps 

31 1 

4 

kbytes/sec 

3 

32 

kbps 

321 

6.4 

kbytes/sec 

= 

51 . 

2 kbps 

41 1 

1 

kbytes/sec 

3 

8 

kbps 

421 

1 

kbytes/sec 

3 

8 

kbps 

431 

1 

kbytes/ sec 

3 

8 

kbps 

51 1 

0 





521 

0 





531 

0 






TRUNK 2 TOTAL OFFERED 1 OAD = 224.2 kbps. 

The aggregate offered data load for trunk 1 is 
80 kbps <6.505 log bits) and for trunk 2 is 224.2 
kbps (6.952 log bits). These offered aggregate 
data rates are less than the desired maximum by a 
considerable amount and room for growth exists. 
There is an allowable factor of 100 for trunk 1 and 
an allowable factor of 10 for trunk 2 growth rates. 
Keeping in mind that this aggregate data load for 


trunk 2 is the same as for the single trunk 
simulation configuration of figure 5.1 it is 
easily discerned that the cross trunk traffic while 
amounting to a 357. increase in trunk 2 traffic 
lowers the maximum operating offered load 

potential of trunk 2 by a factor of almost 4 (down 
from 8 Mbps to 2.5 Mbps) . Furthermore the curve of 
figure 5.5 illustrates that the utilization of 
trunk 1 saturates at 557. as opposed to the 757. 
point for the single trunk case. 

FOR DUAL CONFIGURATIONS IT SHOULD BE NOTED 
THAT THE MAXIMUM AGGREGATE OPERATING LOAD 
POTENTIAL OF THE TRUNKS IS LOWERED BY A 
CONSIDERABLE AMOUNT. THIS ARISES FROM THE 
NECESSITY OF DUAL RESERVATION OF BOTH TRUNK 
ADAPTERS. THE CROSS TRUNK TRAFFIC LOWERS 
THE MAXIMUM OPERATING UTILIZATION POTENTIAL 
TO APPROXIMATELY 757. OF THAT FOR THE SINGLE 
TRUNK. 

FURTHERMORE CARE SHOULD BE TAKEN IN ASSIGNING 
DEVICES TO THE TRUNK ON WHICH THEY ARE MOST 
ACTIVE. 
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5.3 Anal/sis and Conclusions 

The goal of this work was to develop a software 
tool, with particular emphasis on NSC's HYPERchannel 
network, to aid the engineers and scientists at the 
HOSC, to perform system analysis. This study began with 
a description of the HYPERchannel and the various 
protocols implemented by the network. The relationship 
of these protocols to system performance was discussed. 
The system components which make up the HOSC were 
examined, these components are examined for information 
purposes, in that the attributes of these devices were 
used to define the test configurations presented in 
section 5.2. The configurations chosen for testing by 
the simulation, are based on the system shown in Figure 
3.1. The results of this testing are presented in 
section 5.2 of this work. 

The data, which appear in Section 5.2, are plotted 
in all cases versus the Log (base 10) of offered load, 
where offered load is expressed in bits. So that an 
offered load of 7 on any plot is the inverse Log (base 
10 ) of 7 which is equal to 1 x 107 bits. In Figures 
(5.2 and 5.5) utilization is plotted versus offered 
load. Utilization is a dimensionless figure ranging 
from 0 to 1. In Figures (5.3, 5.6, and 5.7) the Log 

(base 10) of transmitted control and data bits are 
plotted versus offered load. As before a value of 7 on 
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the offered load axis represents 1 x 10? bits. Whether 
this is data or control bits, is indicated on the axis 
of its respective plot. Finally, the simulation time 
used, 40 seconds, was the same -for all simulation runs. 

The results obtained -from the single trunk 
con-figuration o-f the model are found in Figures 5.2 and 
5.3. The results as plotted in Figure 5.2 and tabulated 
in Table 5.3, compare favorably with results obtained 
by other researchers CFRAN82], C FRAN84] , and [WATS8Q]. 
While numerical results differ due to different 

topologies being modeled, overall performance of the 
network is essentially the same. The overall 

performance of this network, and that reported 

elsewhere, appears to approach some relatively constant 
level (saturation) as offered load increases. A 

slightly different presentation of these results are 
plotted in Figure 5.3 and tabulated in Table 5.5. This 
data is presented as transmitted control and data bits 
versus offered load. These plots represent the actual 

amount of data and control bits being transmitted by 

the network versus offered load. Control bits are these 
bits transmitted by an adapter to perform network 
functions and are considered overhead loading. Data 
bits transmitted, are those bits offered to the network 
by attached devices for transfer over the network. 


Offered load represents the total amount 


of data 




presented to the network -for transmission over the 
network. Thus, as offered load increases, the amount of 
data bits transmitted should increase. Since network 
services are requested, network -functions increase, 
thereby increasing the amount of network messages 
relating to these -functions. This will cause a 
corresponding increase in the amount o-f control bits 
being transmitted over the network. The plots in Figure 
5.3, both exhibit nearly linear properties until a 
certain point (offered load approximately equal to 9 > 
is reached, aft*r which the data and control bits 
transmitted remain nearly constant. 

An o-f-fered load o-f 9 on these plots, represents an 
aggregate o-f-fered load o-f 3.125 Mbytes/sec being 
presented to the network -for tr ansm i . s i on . This is 
equivalent to an o-f-f network source requesting network 
services every 0.04 usee. According to published 
figures [FRAN823, CFRAN843, and [WATS823 , an adapter 
requesting f he trunk, transmitting its data, and then 
releasing itself and its receiving adapter will require 
a minimum of 940 usee to send one me s sage -w i t h-da t a 
sequence containing one 2 Kbyte data block. If the off 
network sources' data rates are such that network 
services are requested faster than the network can 
process these requests, then data loss will occur. At 
this point the network is entering saturation. This is 
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reflected in the plots of data bits transmitted versus 
offered load. After offered load exceeds the point 
where ottered load is approximately 9, any -further 
increase in the o-f-fered load does not produce a 
corresponding increase in the amount o-f data and 
control bits transmitted. This indicates that the 
network is saturated and can not transmit any greater 
amount o-f data or control bits. 

The normal o-f-fered load to the network, based on 

observations o-f the system described in Chapter 3, and 

\ 

detailed in Appendix It), appears to be approximately 
6.95 (O-f-fered Load). This -figure results -from summation 
o-f the data rates applied to the network, multiplied by 
simulation time, and then performing a Log (base 10) 
operation on the result. Thus this network is. 

according to simulation results, operating below its 
potential by a -factor o-f approx i mate 1 y 100. This 
indicates that expansion o-f this configuration would be 
possible to some extent. 

In order to examine the effects of a second trunk 
added to a network, the configuration shown in Figure 
5.4, and detailed in Appendix U, was modeled. This 
configuration is similar to the single trunk 
configuration in that the topology of trunk 2 (Figure 
5.4) is the same as that shown in Figure 5.1. In order 


to observe the effects on trunk 2 due to another trunk 


having access to it, the probability of a transmission 
to trunk 2 -from trunk 1 was set higher than the 
probability of the reverse operation. It should be 
apparent, that a dual trunk network in which each trunk 
has need of only sporadic use of the other, would have 
noticeably better performance than the configuration 


presen ted 

in this work. The results 

of mode ling 

this 

configuration are plotted 

in F i gures 

5.5 through 

5.7, 

and are 

tabulated in 

Tables 5 . 

? through 

5.9. 

Ex ami nat i 

on of these resu 

1 ts shows 

that trunk 

1 i s 


relatively unaffected, although utilization is lower. 
Utilization in this case is approx i mate 1 y constant at a 
value of 0.55 for increasing offered load. This figure 
is approximately 25% less than the comparable value for 
a single trunk network, this is due largely to the 
topology of the network. On trunk 1 there are two 
adapters, which communicate exclusively with each 
other. There is a 1 arger number of adapters on trunk 2; 
which affects the common adapter to both trunks, in 
that, multi-trunk operation is slower. This slowness of 
the multi-trunk operation may be attributed to the 
common adapter having to compete for a busier trunk to 
complete its' transmission. Thus, the common adapter 
will be reserved for longer periods of time, directly 
affecting throughput, and consequently utilization, on 
both trunks. Performance on trunk 1 of this topology, 
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with the exception of lower utilization, is roughly the 
same as that of a single trunk network, as expected. 
However, the results -for trunk 2 are drastically 
reduced from that of a single trunk configuration. An 
examination of Figures 5.2 and 5.5, show that 

utilization of the trunk is very nearly the same for an 
offered load of approx i mate 1 y 5 to a load of very 
nearly 8. After an offered load of 8 is reached, the 
dual trunk configuration's utilization is drastically 
reduced. In Figure 5.6, the control and data bits 
transmitted over trunk 1 are plotted. These curves 

exhibit behavior similar to that of the single trunk 
model discussed previously. This is not the case for 
the control and data bits transmitted over trunk 2 
(Figure 5.7). Both of these plots exhibit linear 

behavior to a certain extent, but while the control 

bits transmitted are only slightly affected, the 
transmitted data is drastically altered at the same 
point that utilization breaks down. Based on the 
description of this network contained in Appendix V , 
the normal offered load is approximately 7.08. rs shown 
in the plotted data, this topology has very limited 
range in regard to offered load, which makes it 
vulnerable to perform*, .ce degradation due to load 
var i at i on . 
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Thus, a single trunk system exhibits greater 
potential for expansion than the dual trunk topology 
modeled. Rather than allow a dual trunk system of this 
nature, it would be better (Performance related) to 
place the additional device seeking communication with 
another trunk, at a high rate, physically on the trunk 
it requests the most. 

The validity of this simulation is based on the 
understanding of the system and the structure of the 
mode 1 . While it wou Id be better to establish validity 
by comparison with actual configurations and their 
measured performance, the feasibility of establishing a 
test bed for this purpose is remote, due largely to the 
intensive mission r equ i r emen ts at the HOSC . 

Finally, the author believes that the stated 
research goals have been reachea. However, in this 
model, as in all things there is considerable room for 
improvement. Future expansion of the model might be 
made, to include i n tra-adap ter message transfers, and 
more than one adapter to more than one trunk. This 
would serve to lend more accuracy and sophistication to 
the present model . The current model appears to possess 
reasonable accuracy and validity, with the stated 
conditions under which it was developed. 


Ij.6 


APPENDIX I 


So-ftware Source Listing 
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PROCRAM S I M 1 (INPUT/ OUTPUT/ OfILE (LEN«17>/ AUXOUT (LFN«16>/ OUT (LEN«1SI) 


CONST 

.RAXNU»SOURCES » 3; 

NAXNUNAOAPTERS * 9; 
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TRUNKRATE * 50.CE*66; (• TRUNK TX RATE IN STTS/ SECS 
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If THUNKS THEN 
BEGIN 

f 0 H 1 :» ( CONNAP ♦ 1 ) TO NUNOf ADAPTEHS DO 
BEGIN 
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7 5 9 WITH ADAPTERCIU] DO 

750 BEGIN 

751 FOR L :» 1 TO * 0 

752 IF OFLAGCL] THEN 
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2309 WITH ADAPTEHCTAJ.DEVICECT03.S0URCECTS3 DO 

2310 WITH ADAPTERCTA).DEVICECTD 3 00 

2311 WITH A 0 APTERCTA 3 DO 

2312 BEGIN 

2313 TRK 2 TALLY :* TRK 2 TALLY ♦ 1 J 
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2364 IF TRUNKS THEN 

2365 BEGIN 

2364 PER1ACTIVE :»<TR1ACTIVE / CURRENTTIHE) • 1001 

2367 PER2ACTIVE :*<TR2A£TIV£ / CURRENTTIHE) • 100; 

2163 PERTACTIVE : = ( T I HE AC T I V E / CURRENTTIHE) • 103/ 
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2529 

2530 

2531 <• 

2532 PROCEDURE * CT J V I T T SUPP* R r; 

2533 <• 
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2535 C NETWORK COLC START CONDITIONS 

2586 

2587 initialize; 
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2639 IF Ml OR M2 OR M3 OR M4 OR MS OR M6 Then 

2640 BEGIN 

2641 IF (NEXTTX >* C AR DmN • TOTALDELAY) OR (NEXTTX • CAROJN ♦ FIXEOOELAT 

2642 ♦ PR I DEL AY > THEN 

2643 BEGIN 
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APPENDIX II 

Summary of ISO-OS I Model of Distributed Networks 


Layer 

1 . Physical 


2. Data Link 


3. Network 


4. Transport 


Definition 

Concerned with transmission of 
unstructured bit stream over physical 
link; involves such parameters as 
signal voltage swing and bit duration; 
deals with the mechanical, electrical, 
and procedureal characteristics to 
establish, maintain, and deactivate the 
physical link. (RS-232-C, RS-449, X.29) 

Converts an unreliable transmission 
channel into a reliable one; sends 
blocks of data (frames) with checksum; 
uses error detection and frame 
aknowl edgemen t ( HDLC , SDLC, BiSync) 

Transmits packets of data through a 
network; packets may be independent 
(datagram) or traverse a preestablished 
network connection (virtual circuit); 
responsible for routing and congestion 
control. (X.25, layer 3) 

Provides reliable, transparent transfer 
of data between end points; provides 
end-to-end error recovery and flow 
control 


5. Session Provides means of establishing, 

managing, and terminating connection 
(session) between two processes; may 
provide checkpoint and restart service, 
quarantine service 


6 . Presentation Performs generally useful transform- 
ations on data to provide a standard- 
ized application interface and to 
provide common communications services; 
i.e., encryption, text compression, 
reformat t i ng 


7. Application Provides services to the users of OSI 
environment; i.e., transaction server, 
file transfer protocol, network 
man agemen t 

This summary taken from, Local Networks, An 
Introduction, by William Stallings [ STALL84] . 
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APPENDIX III 

Simulation Software Module Descriptions 


1 . S i ml . 

Siml is the top leu el procedure of the simulation 
program. It controls simulation activity and flow in 
the simulation environment. Referring to Figure 4.2, 
the first f hree blocks perform variable initialization, 
define the simulation network conf i gur at i on , and prints 
a description of the network in the auxiliary file 
Auxout. The loop indicated is the actual simulation 
activity (described in subsequent sections). Siml will 
print compiled overall network statistics to the system 
default output device and to the auxiliary file Auxout, 
by invoking Printstats. The procedure Ac t i v i tysummar y 
prints a breakdown of the network statistics by device, 
to the auxiliary file (Auxout). 

2. In i t i al i ze 


Th i s 

procedure i 

is used 

to 

initialize certain 

gl obal var i abl es 

wh i ch 

need to 

be 

spec i f i ed for each 

execu 1 1 on of 

the 

pr ogr am 

. Table 

1 1 I 

.1, is a listing of 


the interactive queries posed by this procedure, along 
with any constraints involved. The remaining variables 
which do not require user- i n terven t i on are also 
initialized in this section. 
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Table III.l Interactive Queries Posed by INITIALIZE 


Query : 

Response : 


Ex amp 1 e : 
Var i abl e : 


Is there more than one Trunk ? Y! es or N)o 

Y or N, i -f answered yes then the 
•flag Trunks is set true, otherwise, 
Trunks is set -false. 

Y 

Trunks = True 


Query : 
Response : 


Ex amp 1 e : 
Var i abl e : 


Identification heading for run: 

Valid responses are alphanumeric strings 
with length less than 50 characters. 
Heading appears on each output page. 
Simulation Configuration Test 
Headi ng 


Query: Maximum run time in seconds 

Response: Valid responses are real positive numbers 

which represent the time a simulation run 
will execu te 
Ex amp 1 e : 40 

Var i abl e : Max t i me 


Query: Maximum Successful Sequence Transmissions ? 

Response: Valid responses are real positive numbers 

which represent the number of successful 

message -w i th-da t a sequences will be 
transferred over the entire network 
simulation ends when Maxseqtx or Maxtime 
i s exceeded 
Examp 1 e : 100000 

Variable: Max&eqtx 


Quer y : 
Response : 


Ex amp 1 e : 
Var i ab 1 e : 


Seed for Random Number Generator 

Integer number. For best results, the 
number specified should be an odd, 
positive number with at least 5 digits 
and not divisible by 5 or 7. 

16227 

U 


The following queries will be posed if Trunks is True. 

Query: Was the last Run a Single Trunk 

Configuration Y)es or N)o 

Response: Y or N, if answered yes, Inputmode = 

interactive, thus forcing redefinition of 
the network. If answered no then the 
following query will be posed. 

Ex amp 1 e : Y 
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I npu tmode 




Var i abl e : 


Query s 
Re sponse : 


Ex amp 1 e : 
Var i abl e 


Input Modes interactive or F)ile ? 

This query will be posed only if 
the last run was a dual trunk 
configuration, this is indicated by 
answering no to the above query 
If answered F, the network configuration 
used will be read out of the Df i 1 e . If 
answered I, then the network will have 
be redefined by the user 
F 

I npu tmode 


The following queries will be posed if Trunks = False 

Query: UJas the last run a Dual Trunk configuration 

Y)es or N)o 

Response: As before, yes will force redefinition 

of the network and no will cause the 
next query to be posed. 

Ex amp 1 e : N 

Variable: Inputmode 


Query : 
Response : 


Ex amp 1 e : 
Var i abl e : 


Input Mode: interactive or F)ile ? 

As before, answering no to the above 
query will allow this querv to be posed. 
The effect of this query is the same as 
above 
I 

I npu tmode 


3. Character i zeNetwork 


Procedure Charac ter i zeNe twork establishes the 
experimental framework of the simulation. The 
individual adapters, devices, and sources are defined. 
There are two ways tc establish an experimental model, 
interactively, or from an auxiliary file (Dfile). The 
method employed is determined by the '*slu? of 
Inputrroue, defined by procedure Initialize. If 
Inputmode is equal to interactive, then the system 
description will be provided by the user interactively. 
A sub-procedure RewriteDfile will be called to store 
this interactive system description in the Dfile. If 
Inputmode equals file, then the system description used 
is the one stored in the auxiliary file (Dfile), 
implying a previous run where Dfile was created 
interactively. A detailed listing of the interactive 
queries posed by Ch ar ac ter i zeNe twork is presented in 
Tabl e 1 1 I .2. 

4. Pr i n tne tDescr i p t i on 

The p" v^ose of this procedure is to print a 
detailed descr i ,-i t i on of the system being modeled in the 
auxiliary file Auxout. 

5. Fi ndNext(Tmi tter ) 

As previously stated this model is a discrete 
event simulation. The event which drives the simulation 
is an adapter's next scheduled transmit time. The 
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Table 1 1 1. 2 Queries Posed by CHARACTER I ZENETWORK 


Query: Length of Trunks in -feet (used -for end 

de 1 ay ) 

Trunk 1 : 

Trunk 2: < appears -for dual trunk ) 

Response: Positive real numbers 

Variable: TrunklengthtI] 

Query: Number o-f Adapters in Network: 

Response: Integer number in range 1 to Maxnumadan ter s 

Variable: Numof adap ters 

In the Dual Trunk case the following query will be made 

Query: Wh i ch Adapter is Common to both Trunks ? 

Response Integer number in range 1 to Maxnumadap ters 
Variable: Commad 

Query: Adapter #i : Distance in ft. from priority 1 

adapter on Trunk 1 
Response: Positive real numbers 

Variable: Adap ter C i ] . d i stf romAl 

Query: Adapter Priority: Give in integer 

form , i . e . , n 1,2,.... 

Response: Positive integer numbers 

Variable: Adap t er p [ i 3 . PI 

Query: Adapter Retry Count: This must be a unique 

number for each adapter, in the range 0-64 

Response: Positive integer numbers 

Variable: Adao terp [ i 3 . r e tryc t 

The following two queries are made for the common 
adapter two both trunks 

Query: Distance i r» ft. from priority 1 adapter on 

Trunk 2 

Response: Positive real numbers 

Variable: Adapter! Comm ad 3 . D i s t f r tAl 

Query: Adapter Priority: Give in integer 

form, i.e., n = 1,2, 

Response: Positive real numbers 

Variable: Adap ter [ Ccmmad3 . P2 

Query: Adap ter t i 3 . Dev i ce [ j 3 desc. iption 

Device status (Open or Closed) 

Response: 0 O' C. C if Adap ter C i 3 . Dev i ce [ j 3 

has an active, network oevice con- 


* 


17.1 


Mar i abl e : 

Query : 
Response : 
Mar i ab) e : 

Query : 
Response : 

Mar i abl e : 

Query : 
Response : 

l />ar i abl e : 

Query : 
Response : 

Mar i abl e : 

Query : 
Response : 

Mar i abl e : 

Query : 
Response : 


Mar i abl e : 

Query : 
Response : 

Mar i ab 1 e : 

Query : 
Response : 


Mar i ab I e : 


nested to it. 0 otherwise. 

Adapter! i ] . Dev i ce [ j ] .Open 

Device ID < <= 24 Char) 

Alphanumeric string 
Adap tert i ] .Devicetj] .Id 

Device to Adapter I/O rate (Bytes/sec) 
Positive real number representing the speed 
o-f the device I/O port. 

Adap terti ] .Devicetj] . t-ferrate 

Number o-f Data Sources in Devicetj]: 

Integer number representing the number of 
data sources supplying the device with data 
Adap tert i ] . Dev i ce C.j ] .Numot sources 

Data Sourcetk] ID: 

Alphanumeric string with length <= 24 
char ac ters 

Adap tert i ] .Devicetj] . Source [ k ] . I d 

Sourcetk] Data gen rate (Bytes/sec) 

Real number, representing the rate at 
which data arrives at device. 

Adap tert i ] .Devicetj] .Sourcetk] .Genrate 

Bu-f-fer size in bytes 

Integer number, size of bu-fter tilled in 
device before network transmission is 
requested. 

Adap tert i ] .Devicetj] .Sc j- : e t k ] .Buttersize 

Receiver Id code ? <0 to end list) 

3 digit integer number, representing 
Adapter#, Dev i ce#,and Source# 

Adap tert i ] .Devicetj] . Source t k ] .Id 

Probabi 1 i ty ? 

Positive real number 0 < number <.= 1 
representing the relative probability 
that the above receiver will be trans- 
mitted to by this 
adapter! i I .devicetj] .sojrcetk] 

Adapter t i ] . Devicetj]. Source t k ] . Prob 
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procedure FinoNext scans all adapters and picks the one 
with the smallest next time to transmit, compared to 
( Cur ren t t i me > simulation time. After selecting one 
adapter, it will then determine if this adapter is 
reserved for a reception of a message sequence from 
another adapter. If the adapter is reserved, then it is 
forced to wait, if not reserved then it is returned to 
the main program as the current transmitter. 

6 . Pi ckA(Tmi t ter ) 

This procedure is used to pick a receiver for a 
transmitting adapter. The current transmitter's 
attributes are passed to this procedure, and an 
aopropriate receiver is selected based on its list of 
possible receivers and the relative probability of the 
adapter being a receiver for the transmi t ter . This 
procedure also determines whether a transmitter is 
attempting to transmit to a different trunk. If 
attempting a dual trunk communication, the transmitter 
is assigned an intermediate receiver which is common to 
both trunks. 

7 . ACol 1 i s i on 

The purpose of the boolean function ACol li si on, is 
to determine whether or not the current transmitter has 
unrestricted use of the simulated transmission medium. 


If another 

dev i ce 

attempts 

to transmit 

during a 

t i me 

period of 

equal 

to , or 

less than 

, twice 

the 
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propagation time between the two, a collision condition 
will be declared. Thus, ^Collision scans the network 
devices comparing their next transmit time to the 
current transmitter's next transmit time and determines 
whether or not a collision has occurred. In dual trunk 
simulations the -function ACollision will scan which 
ever trunk is being used by the current transmitter. I -f 
a collision is declared, then collision statistics are 
updated, and both the current transmitter's and 
colliding adapter's next transmission times are 
updated . 

8. Uni -form 

The Uniform procedure functions as a Random Number 
Generator. It generate j pseudo-random numbers in the 
range 0 < number < 1. This procedure is used in various 
sections of the simulation in order to inject some 
randomness in the selection of receivers and in var>ing 
some time parameters. 

9 . Update 

Update is the procedure in which the bulk of the 
MYPERchannel protocol is modeled. As previously stated, 
the simulation is driven by a discrete event. This type 
of simulation is often referred to as activity 
scanning, or event scanning. The event which drives the 
simulation is a transmit request by an adapter. Each 
device is assumed to possess certain attributes 
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determined from 

observat i ons of 

the 

real system. 

As 

an 

ex amp 1 e 

of this 

, if a device 

receives data from 

an 

of f-ne t 

source 

to transmi t over 

the network 

at 

an 

average 

rate of 

15 K i 1 oby tes 

per 

second, and 

stores 


this data in a 2 Kbyte buffer, it will request a 
network transmission every 0.1365 seconds. This then 
serves to generate transmission requests for the 
simulation and in turn, becomes the event which drives 
the simulation clock. 

This procedure consists of seven cases, each o-f 
which updates the current transmitter according to 
where it is in a me ss .;ge -w i t h - da t a sequence 
transmission. The time periods involved are illustrated 
in Figure 4.1, where the individual cases are indicated 
and the program -flags that signal the case an adapter 
will go to on a transmit request. 

Casel: The -first time an adapter signals a request 
to transmit there will be no message flags active, 
indicating the beginning of a message sequence. Casel 
will be invoked and the adapter will reserve itself, 
initialize delay to 1 usee and retry to zero 
(reservation scheme), set Ml true, and adjust its next 
time to transmit by 64 usee. 

Case2: This case incorporates the adapter- 

entering 


reservation scheme (Figure 2.9). An adapter 
(Case2, Case3, Case4, Case5, Case6, or Case?) 


is first 


checked to see if it is involved in a collision with 


other devices. If no collision is detected the adapter 
is checked for dual trunk communication, if it is, then 
an intermediate destination is determined. If not, then 
the adapter's intended receiver is checked to see if it 
is reserved by another adapter. If the intended 
receiver is not reserved, then the receiving adapter 
will be set reserved. Appropriate adjustments to the 
various transmission times, bit counts, message flags, 
and trunk parameters are made. If, however, the 
intended receiver is already reserved, the transmitting 
adapter will enter the retry-delay reservation scheme 
and ; ts message flag will not be changed. Thus, the 
adapter will return to Case!', each time selected until 
it reserves a receiver, or aborts its transmission. If 
a collision is detected when entering (Case 2, Case 3, 
Case 4, Case 5, Case 6, or Case?) then, appropriate 
adjustments to adapter and trunk timing is made. 

Case3: This case deals with the message proper 
portion of the message sequence. If no collision is 
detected, adjustments are made to the adapter and trunk 
parame ter s . 

Ca«e4: This case is essentially the same as Case3, 
with the exception of the values used to update adapter 
and trunk parameters. 
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Case5: In Case5 a determination of how many data 
sequences need to be transmitted is made, this based on 
the size of the data buffer of the transmitting source. 
The first sequence will be updated and if more than one 
sequence is to be sent then message flag M4 will not be 
changed. Appropriate timing adjustments are made in 
this section also. 

Case6: When all data sequences have been sent, 
Case6 is invoked. Appropriate timing adjustments are 
made in this section. 

Case7: There are three possibilities encountered 
in this section: same trunk communication, adapter to 
common trunk adapter communication, and common trunk 
adapter to adapter communication. The last two in 
combination comprise a dual trunk communication. In all 
cases this is the termination of a message sequence. 
Both, the receiver and transmitter are released, and 
appropriate timing adjustments are made. 

10 Printstats 

This procedure compiles and writes to ‘he system 
default output device, and auxiliary file (Auxout), an 
overall summary of network activity. Examples of this 


f o 1 low: 


Single Trunk Simulation Results 


*** End of Run Network Statistics *** 


Current Time : nn.nnnn secs 


Successful Sequence Transmissions 
Collisions (Frames; 

Wa its ( Frames) 

Total Attempts (Sequences) 

Total Aborts 


: nnnnn 
: nnnnn 
: n . nE+nn 
: nnnnn 
: nnnnn 


Total Trunk Active Time 
'/. Total Active Time 


:nn .nnnn secs 
: n n . n n n V. 


Control Bytes Transmitted 
Data Bytes Transmitted 
Total Bytes Transmitted 


:n.nnnnnE+nn Mbytes 
:n .nnnnnE+nn Mbytes 
:n. nnnnn E+nn Mbytes 


Total Offered Load 


sn.nnnnnE+nn Mbytes 


Dual Trunk Simulation Results 


*** End of Run Network Statistics *** 
Current Time : nn.nnnn secs 


Successful Sequence Transmissions 
Successful Sequence Transmi ssi ons-Trunk 1 
Successful Sequence Transmi ssi cns-Trunk 2 
Collisions (Frames) 

U)a its ( Frames) 

Total Attempts (Sequences) 

Total Aborts 

Attempted Trunk -Trunk Transmissions 
Successful Trunk-Trunk Transmissions 
Trunk 1 Active Time 
Trunk 2 Active Time 
Total Trunk Active Time 
/ Trunk 1 Active Time 
V. Trunk 2 Active Tjme 
/ Total Trunk Active Time 


: nnnnn 
: nnnnn 
innnnn 
: nnnnn 
: n . nE+nn 
: nnnnn 
innnnn 
: nnnnn 
innnnn 


n .nnnn 

secs 

n .nnnn 

secs 

n .nnnn 

secs 

nn . nnn 

V. 

nn . nnn 

7. 

nn.nnn 

7. 


Control Bytes Transmitted 
Data Bytes Transmitted 
Control Bytes Transmitted 
Data Bytes Transmitted 
Total Bytes Transmitted 
Total Offered Load 


Trunk 

1 

: n . nn 

Mbytes 

Trunk 

1 

: n . n n 

Mbytes 

Trunk 

2 

: n . nn 

Mbytes 

Trunk 

2 

: n . nn 

Mbytes 



:n.nn 

Mbytes 



: r. . n n 

Mbytes 
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11. Activity Summary 


O' 


This procedure prints detailed breakdown by 
device, of network activities. This summary is printed 
to the system de-fault output device, and the auxiliary 
file (Auxout). The categories detailed are as follows: 

Time Active: Time device spent trans- 

mitting and receiving. 

Time Waiting: Time device spent waiting 

to transmit due to its 
adapter De i ng reserved. 

Time in 

Collisions: Time involved in collisions 

by device. 

Average Message 

Delay: This is the average time 

length of a message 
sequence sent by this 
device. If this number is 
0, either the device can't 
transmit, or it tried to 
but never sent an entire 
message sequence. In the 
latter case, message delay 
would have to be > than 
simulated run time. 

Abort count: Number of aborted transmis- 

sion attempts (reservation 
scheme ) . 

Transm i ss i on 

Count: Number of successfully 

transmitted sequences 

Reception Count: Number of successfully 

received sequences 

Wait Count: Number of times device 

had to wait to transmit 
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T*‘ 'IT 

it* 




Collision Count: Number o-f times engaged 

in a collision, (note: 
these numbers are actually 
double the total shown in 
overall statistics due to 
one count -for each col- 
1 i d i ng adap ter . 
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APPENDIX IV 

Typical Single Trunk Simulation Results 
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Typical Dual Trunk Simulation Results 
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PRIORITY DELAY ON TRUNK 2 : 0 .000002 2 SEC S 
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